Agile techniques: Benefits of test-driven development - Part 2

Test-Driven JavaScript Development author Christian Johansen describes the benefits and the time required as well as answering some tough questions about how to ensure the quality of the tests themselves. 

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy. 

Please check the box if you want to proceed. 

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests.  I may unsubscribe at any time. 

Please check the box if you want to proceed. 

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent. 

time on test cases before application code is even written.  In part one of this two-part interview with Christian Johansen, author of Test-Driven JavaScript Development, described the mechanics of TDD and how it compares to traditional unit testing.  In part two, Johansen describes the benefits of the technique and encourages developers to take the time necessary to gain cleaner code.  Read part 1. 

You mention that TDD was borrowed from Extreme Programming.  I know I've often heard TDD used in the context of agile methodologies, yet unit testing is practiced with waterfall and other traditional methodologies as well.  Do you find that TDD is "methodology-agnostic"?  Is there any reason why it wouldn't be equally relevant regardless of methodology being used?TDD came along with Extreme Programming, yes, but it is one of those practices that you can borrow no matter how your project is organized and still benefit from it.  As I've explained, TDD is a programming-level activity, and there is no reason why a programmer in a waterfall project should not be able to benefit from it.  Reduced number of defects, increased confidence in code and increased ease of maintainability should be desirable goals regardless of project methodology. 

It seems that the time to write, test and maintain the automated tests required for TDD would require almost the same amount of time it would take to write the application code.  Is this true?  Does anyone test the test cases?Writing tests takes time, for sure.  However, writing tests also saves time by removing or vastly reducing other activities, such as manual or formal debugging and ad hoc bug fixing.  TDD also has the ability of reducing the total time spent writing tests.  When retrofitting unit tests onto a system, a programmer will likely occasionally encounter tightly coupled code that is either hard or impossible to test.  Because TDD promotes the unit test to the front seat, testability is never an issue. 

Do tests required for TDD require almost the same amount of time it takes to write the application code?  Maybe not exactly as much, but not far from it.  But you have to look at it from a wider angle-- you spend more time writing tests, and probably a little less writing production code.  All in all, initial development time will be slightly raised, but experience tells me you reap the benefits over time in reduced number of defects and improved maintainability, even though I cannot provide you with hard numbers to back me up on that. 

Does anyone test the test cases?  This is the question I am asked most frequently when presenting unit testing to uninitiated programmers.  The answer is no, but that does not mean we don't take measures to make sure tests do not contain bugs, and this is another area where TDD helps over traditional development (where tests are written after the fact). 

The first redeeming fact is that unit tests should be very simple-- no branching logic, just a set of simple linear statements that sets up an initial state, exercises a method or two, and then finally makes assertions on the results.  Keeping the test code simple reduces the chances of bugs.  The second fact is that in TDD, tests should always be run immediately after they are written.  At this point we can confirm our expectations as to how and why the test fails.  If the outcome is not as expected here, we are prompted to double check the test, and in fact I find that most errors I make in tests are caught this way. 

Any final words of advice for those interested in practicing TDD?  Start writing tests and practice.  Mastering TDD takes practice, and the benefits become clearer the more you get the hang of it.  If you are completely unfamiliar with unit tests, start by trying to write tests for your existing projects and develop new features test-first.  Code katas (http://codekata.pragprog.com/2007/01/code_kata_backg.html) also make for excellent practice - think of them as small exercises you can do over and over again to flex your programming and TDD muscles.  And lastly, I would of course like to recommend reading my book, 'Test-Driven JavaScript Development', which deals with unit tests, JavaScript and TDD in great detail, including lots of real world TDD examples.  Read part 1. 

Christian Johansen is author of the book, Test-Driven JavaScript Development, published by Pearson/Addison-Wesley Professional, Sept. 2010, ISBN 0321683919, Copyright 2011 Pearson Education, Inc. For more info on the book, please visit the author site.  For a complete table of contents, please visit the publisher site. 

0 comments

Register

Login

Forgot your password? 

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners.  If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.  Privacy