How does test-driven development, fit into the greater world of testing and deployment? Let's take a look. The world of software testing is broad. There are literally dozens of disciplines. Each with their own names like smoke testing, and load testing. Each of these testing disciplines goes to a specific level of depth, tests or measure something specific. It takes place at a specific time in the development process, or as tested by a specific group. One example is smoke testing. Which literally tests only to see if something catastrophic is wrong at the level of being on fire. Another example is load testing. Which measures the ability of a system to scale, to a desired capacity. We're trying to see where TDD contributes to quality assurance. We need to go back, and look at the traditional four levels of testing. The smallest to the largest levels are. unit test, testing individual components, integration test, tests two or more components together. System testing, tests all pieces of the software together. And acceptance testing, which reviews the final system from the customer perspective. Unit tests are the focus of test-driven development. They can be automated in a way that runs quickly. They're at the level that an individual developer works. All TDD tests are unit tests, but not all unit tests are TDD. There are two types of testing, manual and automated. manual testing as the name implies, is done by hand. It's the most traditional kind of testing, and is the most similar to the quality assurance efforts. Outside of the software industry. Automated testing requires no human intervention, because software in its essence is pure information. There's virtually no part of software testing, that can't be automated. One thing that's difficult to automate, is the user interface. The layer on top of a software system that the user interacts with. The one that, for instance, displays buttons and interprets mouse clicks. For the most part, the user interface is made as thin as possible. So as to keep as much of the software, as testable as possible. The progenitors of TDD, said that testing the user interface. Is like testing a constant, is pi equal to 3.14? Today, decades later, the user interface is more important than ever. We've made great strides in creating automated test for them. But they're still not the focus of TDD. Let's see where all this focus on testing has gotten us. With the rise of automated testing in the popularity of unit tests in specific. Some new ideas and capabilities have arisen. Specifically, the idea that we can eliminate virtually all manual testing. And possibly work without a quality assurance department. Well, at least for some stages of development. This aligns with the TDD philosophy, as it moves the responsibility for quality to the developers. This requires that every single function in the system has at least one test, associated with it. The percentage of lines of code that are associated with tests, is called code coverage. You would want code coverage to be as close to 100% as possible, to make all this work. This drive for total automation of quality assurance, is part of the reason for the resurgence of interest in TDD. Let's find out what this near total automation has enabled. This empowerment of developers to take complete responsibility for the systems they work on extends also into the deployment and maintenance of production systems. This is called Dev-Ops, short for development operations. Dev-Ops includes two new processes, known as CI, continuous integration, and CD continuous deployment. They're called continuous because rather than doing them on demand. And late in the software development life cycle. They're triggered automatically every time source code is committed. Or merged into specific branches or repositories. Some companies do multiple feature releases, every single day. Our test driven development, can contribute to this kind of capability.
