Why You Should Implement Test Driven Development (TDD)

For the vast majority of developers, writing unit tests were short bits of throw away code. They would write some code just to verify that their programs worked. Classes and methods would be written and then some adhox code would be written to test this code. Test code these days is just as important as writing your production code and it must following the guidelines that you have set to write your production code, such as naming your methods and variables so that they are understandable by any developer.

The Benefits of Test Driven Development

Usually developers write their production code before writing any test code. I have been a culprit of this as well. In an agile development practise, test code should be written first, Why? Well it ensures that your software design becomes modular. This allows the developer to focus their attention to a single feature and not moving to the next task until the test has passed. This method certainly contributes to a better solution architecture and enforces a modular software design and teaches developers to keep code clean.

Another advantage of test driven development is that it allows the code to be easily maintained. This allows the code to be much easier to deal with when it comes to modifications. With test driven development, developers normally produce cleaner, more readable, and manageable code. By focusing on smaller code chunks is much less effort for developers and it’s easier to adhere to test requirements.

Another important benefit is that code refactoring is alot smoother. Have you ever tried to maintain code for a project that does not have any structure and is not testable? You are afraid to change anything just incase you break something. Or you make a change and the site breaks in many other places. I have seen this situation too many times. With test driven development you have the confidence in refactoring your code because you know upfront if there are going to be any issues in the site with the changes that you have made.

With test driven development the project cost decreases and your ROI increases. You may not see this at first and think that writing unit tests takes a lot more time and will increase the cost of the project. Developers should not think like this. In the long run writing unit tests will actually save your client money as you can identify bugs immediately and not wait for the client or customer to tell you there is an issue. Test driven development can reduce the time to market speed, overtime reducing the projects cost while increasing code quality and mitigating the risk of failure.

The Three Laws of Test Driven Development (TDD)

Law #1:
You may not write production code until you have written a failing unit test.

Law #2:
You may not write more of a unit test than is sufficient to fail.

Law #3:
You may not write more production code than is sufficient to pass the currently failing test.

These three laws lock you into a cycle and is perhaps thirty seconds onlg. The test and production code ar written together, with the tests just a few seconds ahead of the production code. Working this way you will write many tests a day, hundreds of tests a month and thousands of tests a year. By workng this way, our tests will cover the majority of our production code.

Keeping Tests Clean

Writing test code is just is crucial to ensure that your software code is bug free. Just as I have stated before that your production code must be clean code, i.e. variables and methods and class names must tell the developer exactly what they are used for. Your test code must be the same, it must be clean because if it isn’t you will most likely lose your code and you will lose everything that will keep your production code flexible., maintainable and reusable.

The reason is simple, having tests, you do not ferar making changes to your code. Without tests, every change is a possible bug. No matter how flexible your architecutre is, or how partitioned your design, without tests you will be reluctant to make changes because of the fear that you will introduce undetected bugs. The higher your test coverage, the less you fear. You may make changes with the code and no upfront if the change that you have made has introduced new bugs.

Now if your tests are dirty, your ability to change youor code is hampered, and you begin to lose your ability to improve the structure of your code. The dirtier your tests, the dirtier your code becomes. Eventually you lose the tests, and your code rots.

Using the F.I.R.S.T. Principle

Clean tests should follow the FIRST principle:

Test should run fast, when test run slow you will be less inclined to run them frequently. If you don’t run them frequently, you won’t find the problems enough to fix them easily.

Tests should not be dependant on each other. One test should not setup the conditions for the next test. You should be able to run the test independently and in the order you like. When tests depend on each other, then the first one to fail causes a cascade of downstream failures, making the diagnosis difficult and hiding downstream defects.

Tests should be repeatable in any environment. Tests shpuld be run on the production environment, QA environment or locally on your PC.

The tests should have a boolean output. Either they pass or fail. You should not have to read through log files to determine if a test has passed or failed.

Tests need to be written in a timely fashion. Tests should be written prior to the production code is written. If you write tests after the production code is written, you may find the production code hard to test. You may not design the production code to be testable.

Leave a Reply

Your email address will not be published.