Test driven development, or TDD, is a method of directly coupling testing with every part of your daily development. Developers who use TDD typically start developing by first writing a test that fails, and then writing the code that makes the test pass. This approach means that product code is more likely to get high test coverage, and the tests typically come first.
Many developers find this pattern useful to help them prioritize good architecture from the start of development, and to stay laser-focused on each part of the functionality they need to implement. This school of thought advocates for testing not being an after-thought of development, but rather a driving force.
For example, in the following image, you can see thatAddTestis written and failing while theAddmethod has yet to be implemented. This test will fail until the method is implemented.
There's a type of TDD calledRed/Green/Refactor. It's a good one to know about because it provides further order to this process. Here's how it works:
Write a failing "red" test.
Add the necessary product code to make sure that your test passes or turns "green."
"Refactor" now that you have the correct functionality.
The following diagram provides a visual of this type of TDD.
There are many reasons you might be interested in starting testing:
Educational purposes: Your professor just asked you to add tests to your code.
Improving code quality: You are working on an assignment and are interested in improving code quality and catching bugs faster.
Peer discussion: Another student or project team member asked what your code coverage is like in a discussion on code quality.
Changing requirements: The behavior of your app is growing quickly, and you need a formal way to capture and check all functionality as your project continues to scale.
The following session and associated Microsoft Learn module covers why we test, and provides a brief introduction to best practices for testing software. We'll go over different types of testing, starting at the most fundamental level, unit tests. We'll also touch on various schools of thought around testing.
There are lots of testing technologies out there, but no matter your language or software stack, this guidance should help you grasp the basic concepts and help you avoid common pitfalls.
We'll learn the capabilities of tests, and help you decide when to use different types of tests and different schools of thought:
Identify: what can testing help you achieve?
Choose: what types of tests will help you achieve your goal?
Exercise: what testing schools of thought will your team follow to improve testing habits?
What is the main goal?
By the end of this session, you'll be able to evaluate how testing can improve your code quality. You'll also be able to describe how different types of testing.
We also have this dedicated Microsoft Learn module where you will learn more about the testing pyramid, and different testing schools of thought answer the demands of modern development.
In this session, you've hopefully learned more about the purpose, concepts, and schools of thought behind testing, and how they can help you improve your code quality.
Explored concepts: We explored the concept of testing and how it can help catch bugs before the release of your software.
Explained benefits of testing: Testing helps validate code changes, improve architecture, and improve code health.
Learned about different types of testing: Different types of testing can address different needs in a code base.
Discovered different schools of thought: We explained various schools of thought in testing that help guide good practices across teams.
Hopefully, you saw how testing can both document and verify behavior. Tests enable you to automatically check functionality without needing to consciously walk through every supported scenario. Any app that is constantly growing can make use of tests to verify that new functionality doesn't break old behavior.
Learning about the different types of tests can open up new ways of verifying your code. Maybe your unit tests confirm the validity of some changes, but a performance test catches that a function is now taking twice as long to run. Maybe the unit tests and performance tests pass, but your UI tests catch strange UI rendering behavior. Testing from multiple different perspectives improves the quality of your app before it reaches customers.
The testing schools of thought recommend different styles of testing that can drive teams towards better architecture and higher code coverage. You don't have to follow each testing discipline perfectly. Just keep in mind, there's plenty of guidance out there for people wanting to evolve their testing practices.