Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Help me see why everyone seems to love TDD?

news.ycombinator.com

Post reply on HN
Print view View original

1–10 of 89 posts

Ask HN: Help me see why everyone seems to love TDD?

#1

Post by thuddle88 »

I've been a developer working for large corporations for the past 4 who are more concerned with "fast" delivery than "correct" delivery. As a result of that, the concept of Unit Testing is somewhat foreign in the environment (I think we have somewhere around 40% test coverage, our unit test suite takes ~40 minutes to run on a dev machine, and new unit tests rarely get written). Unit tests aren't "valuable" to the customer, so they are pushed out in favor of "value" code (features) and the reliance on manual QA testers to catch defects (which doesn't happen).

Imagine you were hired as a consultant to come in here and fix our process. How would you sell TDD to the bosses/managers who only see it as extra work for the same value? I'll admit I'm a little fuzzy on the benefits as well. I'm slightly ashamed to admit that even on my side projects I'm like "I'm totally gonna do TDD you guys!" but that rapidly falls by the wayside.

Re: Ask HN: Help me see why everyone seems to love TDD?

#3

Post by HenryTheHorse »

#1 A change in your current process must be "sold" in the business context of $$savings (faster dev cycle, lower number of bugs, lower cost of support) or increase in developer productivity/utilization or increase in customer satisfaction.

#2 Inadequate unit testing almost always correlates to greater defects in the support/maintenance cycle. So I would recommend gathering some data around it: for e.g., number of open support tickets, hours spent fixing such defects, regression testing etc etc. This must translate to either $$ or Hours "wasted" or additional head-count (required to deal with tickets).

#3 Identify a small but meaningful project to pilot out the TDD process. You will eventually have to develop your flavor of TDD within the constraints of your organization (people, tools, process...)

#4 Run the process for a few months and then compile the "before and after" data. Be prepared for disappointment. Process improvements are not always quick or visible at the surface.

#5 Management avoids things they don't fully understand. Most managers hear "better unit testing" and hear "more time and effort". Instead, they should hear "lower downstream issues, lower support costs, better builds, happier users".

So, can you help them understand the issue better? Just make sure YOU understand why unit testing matters to your company.

Re: Ask HN: Help me see why everyone seems to love TDD?

#5

Post by sharemywin »

You need to look at the time it takes to fix and retest defects caught in Test. As well as defects found and fixed once in production. Then you need to run a couple projects with unit testing and see if the bug counts go down. Or check the areas with unit testing versus not and see which have higher defects rates.

Re: Ask HN: Help me see why everyone seems to love TDD?

#6

Post by PaulKeeble »

As you develop more on a software product it gets bigger, it gets more features and those features interact with each other. We can argue about whether its linear growth, sub linear or more but its going to keep increasing.

Every 2 weeks say you get a new release which has all the features of the previous releases + 2 weeks more. Given a constant supply of QA testers how do you manually test an ever increasingly larger featureset? You don't you skip the regression testing.

Almost all software studios without TDD working with short cycles do risk based testing, they test the new stuff and the things it might break. They don't test the major features if they don't think they were touched. So either you aren't refactoring and hence your code is rotting or you are and that risk based testing is missing areas that did have changes in practice.

TDD changes that, it turns the ever increasing QA cost of regression and new tests into development of tests and the growth is in machine running time for the tests. It flattens the human effort meaning your software is better tested over time and all the old features are tested every release reducing the chances of regressions.

If you don't release fast (12 months between releases) then its less of an issue because there is usually time to have a manual test team go at it and potentially delay release with bugs and regressions and such. But its one of the "G Forces", in order to develop at ever shorter cycles and be more agile to change you need to convert the human effort of testing into machine time and the only way we know of ensuring that happens is TDD.

Re: Ask HN: Help me see why everyone seems to love TDD?

#7

Post by Encaitar »

First thought is the maintainability of the code base. If you are building an iPhone game that will be out of the charts in 3 months and will never be updated, then go ahead with feature code delivery and no tests. If you want your system to still be working in 2 years time and you still be able to add new features to it in 2 years time then you need tests.

The more confidence you can get in your code change the faster you can add features. Comprehensive automated, fast running testing gives you this in spades.

Re: Ask HN: Help me see why everyone seems to love TDD?

#8

Post by bitdivine »

When tests become too slow I make the code and or tests faster until the tests complete in under a minute. Running tests in parallel can help. Even so, with a large set of tests that might be easier said than done but perhaps you can trim them down to the set that are most likely to be relevant and start off by testing just those? There are fancy ways of minimising exploration, working out which tests are most relevant for a given code change, but that is probably for later. Better to get started and then expand!

Re: Ask HN: Help me see why everyone seems to love TDD?

#9

Post by raverbashing »

Taking 40min for the unit tests to run points to a problem, however, I've seen my fair share of "TDD geniuses/advocated" that love doing things that slow everything down (like writing hundreds of minuscule testings where 2 or 3 things could be tested in the same test, big setup methods, etc)

Re: Ask HN: Help me see why everyone seems to love TDD?

#10

Post by TruffleMuffin »

To me, TDD is like a framework (Backbone, React etc). You can do it well and get a lot of value, and you can do it poorly and it serves no purpose. Ill provide an answer to your question, from a business perspective.

The value of TDD when done well is that you are ensuring (to a relatively strong degree, but not perfect) that you don't regress on issues. This isn't something that a human being can do when your system becomes sufficiently large and your introduction of features/deliveries accelerates.

For example, if it takes 1 hour for your QA team to 'system test' your application, and you introduce a new feature every day, that consumes a huge volume of resource over the course of a year. You also run the risk of human error, forgetting steps etc. At the end of the year, your QA team now take 4-5 hours per day to 'system test' your application. Its all they are doing all the time. This is pretty demoralising work.

If it takes 1 hour for one person to write tests that serve the same purpose. Those tests can run within in much smaller time frames and use far less resources than a manual 'system test'. That is a massive saving to the company as over the course of a year you will save hundreds/thousands of man hours and wont degrade morale.

TDD should give you confidence that your application is working as you intend it to be, its a tool and it can be used poorly, but when used well you should see the benefits.

Post reply on HN