The biggest advantage of tests is that you can move (possibly new) devs on to unfamiliar parts of the code base and they can be reasonably confident that they aren't breaking things with their refactors.
Ask HN: Help me see why everyone seems to love TDD?
31–40 of 89 posts
Re: Ask HN: Help me see why everyone seems to love TDD?
#32Taking 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)
Hmm, having a test do anything more than one thing sounds like a functional or integration test.
Do the test run quickly, are they clear and readable, do they help find regression problems, is it reasonably easy to tell what went wrong when they fail, does the time and effort and peace of mind saved exceed that invested (over the life of the project, amortized, sometimes, for the value of iterating quickly)?
These are important questions, whether you call a test integration, functional, or unit, is not an important question.
Re: Ask HN: Help me see why everyone seems to love TDD?
#33Have you actually lived in a TDD world? Actually sat down and did the entire thing? I don't think it is worth it.
Tests are good. Fire manual QA team and hire people to write automated integration tests.
But actually designing your code around tests? It tends to lead to brittle systems that do a lot of dumb things. Write the code what works best, then add some tests around it where required. 40% coverage could be enough for some apps.
Re: Ask HN: Help me see why everyone seems to love TDD?
#34Have you actually lived in a TDD world? Actually sat down and did the entire thing? I don't think it is worth it. Tests are good. Fire manual QA team and hire people to write automated integration tests. But actually designing your code around tests? It tends to lead to brittle systems that do a lot of dumb things. Write the code what works best, then add some tests around it where required. 40% coverage could be eno…
We have automated tests of all types, covering almost everything, but we still find use in our QA team. They also help us write BDD tests.
Re: Ask HN: Help me see why everyone seems to love TDD?
#35Have you actually lived in a TDD world? Actually sat down and did the entire thing? I don't think it is worth it. Tests are good. Fire manual QA team and hire people to write automated integration tests. But actually designing your code around tests? It tends to lead to brittle systems that do a lot of dumb things. Write the code what works best, then add some tests around it where required. 40% coverage could be eno…
> Fire manual QA team and hire people to write automated integration tests.
From experience, this leads to coders coding-to-the-tests. It compiles, it passes, ship it. Does it doing the right thing under stress? Who knows.
Manual QA staff, proper QA staff, do crazy non-linear things that stresses code like customers do. I'll bet they would have caught that bug in the other front-page story about the animal feeders failing without an Internet connection; I had a tester who pulled-out the cat5 on many occasions.
I think I've said it before: automated tests are the entry test to the QA process, not the exit diploma.
Re: Ask HN: Help me see why everyone seems to love TDD?
#36If the managers fail to see advantages of testing approaches, that normally means they are not mature enough to understand the cost of defects.
Most of our process/engineering effort is to prevent defects from happening as soon as possible, because they are costly. Simply put, if a dev costs $$/hour, and he spends a day fixing bugs, the bugs cost at the very least 8x$$, plus the cost of not doing more important stuff.
Mature organisations understand the cost of defects (the later you fix, the bigger the effort) and the advantage of fixing them early. TDD is just a technique (just like proper architecture, proper process, clear analysis, etc) to prevent defects because they are costly.
Run through a couple of defects that you may have found lately and make the calculations for the cost. Explain that if you lower the rate of defects, you dont spend as much. Finally show that TDD can lower the rate of defects.
Re: Ask HN: Help me see why everyone seems to love TDD?
#37For certain kinds of tasks, where I can see pretty clearly going into it what the outcome needs to look like, TDD actually speeds things up for me. It lets me program more 'boldly' in some ways.
However, the really interesting tasks are those where the actual problem is hard to understand well enough to write tests up front. In those cases, I usually just iterate as fast as possible in various directions until I can see the likely path forward, which allows tests to be written, and then proper code written to make the tests pass.
Re: Ask HN: Help me see why everyone seems to love TDD?
#38because it makes you look better than you really are.
just like fashion.
Re: Ask HN: Help me see why everyone seems to love TDD?
#39TDD came out of agile programming which is also more concerned with fast delivery than NASA-style correctness. It's a tool supposed to help you go faster. If you want an agile unit test suite, it has to run in seconds, not minutes. TDD will make this very clear. If you have problems with the test suite being slow, you have to fix it! A test suite that developers actually like to run is an enormous value, maybe especi…
Test suite being slow: you shouldn't have to run all the tests all the time, just bask the code where you are working, run the full suite and take note of the failed tests, then just run constantly these and a few more while coding. Then run again the full suite before going to lunch.
Re: Ask HN: Help me see why everyone seems to love TDD?
#40Robert Martin runs a consultancy. Selling TDD was a differentiator in the market. This doesn't mean that TDD doesn't stem from his ethical/moral/philosophical values. It doesn't mean that using TDD doesn't make him a happy programmer.
What it does mean is that there is a business case for TDD in Uncle Bob's business. Making a convincing business case is how one convinces the bosses/managers.
The metrics depicting the process as in need of fixing are not business metrics. Customers/users don't care how long the tests take to run or how much coverage the unit tests provide. In the context of a business Test Driven Design, Agile methods, Quality Assurance are not ends in themselves.
Redesigning business process is expensive and hard work and prone to failure. Saying "We should start using TDD/CI/Agile" isn't a design. It's too easy and no where near enough work.
Good luck.