General discussion


For the love of TDD!

By mathurashwin ·
In this day and age of open source software development where unit testing and TDD are considered a way of life, I find it appalling that it is just not accepted and enforced at quite a few software development companies.

In my approx. 12 years of experience as a software consultant, I have seen the landscape evolve from minimal developer testing to where its considered a sacrilege to check in your code without at least a test script tracing through it. Some places even have strict rules for the percentage of minimum code coverage that must be met at all times. Writing unit test cases is no longer considered a waste of time and in fact, in my humble opinion, provides for solid documentation which no word or pdf document can even come close to for a developer. Its hard not to see the benefits of a well written suite of test cases that can be run over and over to make sure that you haven't broken any code while making some changes to it.

Why then, do I still find software companies where you need to convince them of these benefits? Why then, do they think that just having a test team suffice for ensuring software quality? Why do they fail to see that having a set of unit tests handy can save them a lot of the developer's and the tester's time (and time = money :))? One might argue that if it takes hours to write the test case itself, there is no gain there. This argument, I've found to be quite far from the truth mostly since once written, the test case can be run multiple times every time a change is made to that functionality, effectively saving a lot of time over the life time of the software. Of course, just writing unit test cases cannot and will not replace the testers job but it does make sure that once something's fixed, it remains so even without a round-trip back from the tester.

The main reason that I've observed for this nonchalance towards unit testing is that this usually happens where the client has 'outsourced' its development work to a 'software' company and where the only expectation back is that the software 'works as desired'... even if it is held together by duct tape :)

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -


by Tony Hopkinson In reply to For the love of TDD!

Unit testing is much rarer than it should be, and TDD is even rarer, because they both require, better developers, an up front investment, a much clearer scope, an inherrent delay in achieveing a deliverable, and of course are hideously risky and expensive top apply to legacy code bases.

Outsourcing only has as much to do with it as an other short term cost cutting measure.

Collapse -

Not really...

by mathurashwin In reply to Nope.

I'd argue that writing unit test cases has nothing to do with the overall scope of an application. I'd also argue that it causes delay or requires better developers. Let me explain...

Unit test cases are for testing small 'units' of code. The overall scope of the application is/ should never be the intention. Hence, the developer doesn't need to know the complete scope to write unit test cases. All they confirm is that 'I've written a small piece of logic and I want to make sure that it works as I intend it to'. Hence, if a programmer can write a piece of logic, writing the test case should be much easier for them. So, they don't need to be better developers just to write test cases, they just need to be responsible developers :)

The unit test cases may not be able to identify any major bugs but they can at least make sure that they identify the things that make the developer go 'duh' after it gets identified in the QA cycle. Also, I cant seem to count the number of times that I've seen a bug getting fixed in a release, only to reappear in another because of some other code change that happened to a different but related piece of code. It is such instances that usually cause the delay in product delivery and not because the developers had to write a few test cases.

If there was a simple but effective rule that every bug fix needs to have a test case that tests it, this would never happen. Also, each time the collective set of test cases are run, after a code change you are making sure that no bug has been re-introduced even without a trip to the QA, saving a lot of time in the long run.

Even though the intention might be cost-cutting for a client for hiring a software development company to build and maintain a piece of software, they really need to make sure that software quality requirements based on unit-tests and code coverage metrics are well defined in the expectations with the firm that they are hiring.

Collapse -

Near Total disagreement, Designing so you can have a useful

by Tony Hopkinson In reply to Not really...

unit test, and more to the point so you can keep having useful ones, is not something you should expect from the technically inadequate, well not unless you have some fetish for being disappointed quickly. I design to test even if I know for a fact that no resources to do so will be immediately forthcoming. Now if you are telling me it should be "easy" and common, I'd agree wholeheartedly. If you're telling me inhouse developers "always" do it (competent or not), I sell bridges I don't buy them....

Collapse -

Posted in wrong place no text

by Tony Hopkinson In reply to Nope.

Related Discussions

Related Forums