Most of us have probably been left to deal with software that at some time in history was loved by all. The business praised the developers on the team for building it so quickly, and the team felt pretty awesome—they were rock stars. Now we need enhancements, bug fixes, and better performance. Unfortunately, no one from the original team is around, and other developers are scared to touch it, because there are no tests, the architecture and design are overly complex, and understanding where to start seems impossible. What was thought to be a great success is now considered an epic fail. Software development isn't just about building something that works, it's also about building something that can be supported and maintained by everyone.
I'm very fortunate to work on a team that understands the importance and embraces things like pair programming and test-driven development (TDD). These are things, however, that you need to re-learn occasionally to make yourself and your team stronger. TDD is not new—in fact it's about 15 years old. Don't fear, practicing it doesn't make you a dinosaur. It's a technique that drives simplicity in your software and creates a safe environment for you and the rest of your development team.
What TDD Isn't
Sometimes TDD is misunderstood. It's not Test-first development, which suggests that all tests are written before the actual implementation. TDD doesn't mean writing tests after the implementation code has been written. TDD does not mean writing a test for every method of every class.What TDD Is
TDD is a technique and a tool used to develop software by following the strategy of red, green, refactor—write a failing test against a public API that supports a small portion of business functionality, write just enough code to pass the test as fast as possible, and then refactor the implementation to ensure standards in design and quality are met and to remove any unnecessary code that doesn't support the business need (i.e. no anticipatory design...when you do this, you're spending your company's money or your customer's money on something they don't want).TDD and Continuous Integration
There are many ways an application can be tested—all of which should be automated in a Continuous Integration (CI) environment. Could all of your functionality be tested using full system integration tests or automated web testing? Sure, as long as you don't mind waiting several hours to find out you broke something.The goal of CI is to inform developers as soon as possible when bugs have been introduced to the application. TDD creates small, isolated unit tests that are intended to run in a very small amount of time. You still need system integration tests and automated web tests, but they should mainly be put in place to verify everything has been configured and/or wired up correctly—there should be little to no overlap across the different layers of automated tests.
100% Code Coverage...Are You Sure?
There are many tools to choose from that will help you determine how well your code is covered by your tests. Unfortunately, many of them won't tell you the quality of your tests. I'll demonstrate how TDD code coverage is different from non-TDD code coverage.The code being tested is the AwesomenessCalc function shown in the Awesomeness Calc fiddle, which will tell you how awesome you are. I test-drove this code in the TDD Jasmine spec runner. I'm using Blanket.js to display the coverage in the spec as I'm developing. As you can see all tests are passing and the code is 100% covered.
Now let's pretend to write the non-TDD Jasmine spec runner after all the implementation code has been developed. All tests are passing and it also appears that the implementation is 100% covered. However, it's not fully covered—lines are getting executed by the spec runner, but the actual expected behavior is not being tested. You can also play with this non-TDD fiddle to see for yourself.
