3 ms·

When I first learned about TDD I thought the same (order of test and implementation does not matter that much). Yet when you do the TDD steps * write a failing

by wirrbel 10y ago

When I first learned about TDD I thought the same (order of test and implementation does not matter that much). Yet when you do the TDD steps * write a failing test (RED) * implement minimal functionality so all tests pass (GREEN) * REFACTOR and overcome the initial revulsion you will get a ton of benefits that you didn't know existed. I'll first give a few that are more on the code quality side * You have a complete test suite, without redundant tests * Tests are usually not that mock-focused [] as the implementation-after-test didn't introduce random roadblockers for testing. tests do assert the relevant properties (tests-later code bases often have code bases that don't assert much or properties you don't care about). * When you write your test first, you basically write a small example how it feels like to use the API you have in mind for solving your problem. This drastically improves quality. Some non-technical benefits of TDD * I find TDD helps me tackle bigger code-pieces where I just don't know how to start implementing. * TDD is programming gamification. You are rewarded with regular, small successes of having added another test and made it green. So whenever you ask yourself: OMG, have I made any progress in the last 3 days, you can actually tell: Yes, I added 15 tests and made them pass - I objectively got closer to implementing that feature. * Not an issue where I work, but have often heard about this from other places: If tests are there first, no one can tell you to not spend so much time on writing tests. TDD-style is protecting your boss from shipping that car without having the brakes checked. * The same line: TDD gives explicit room for refactoring. [*] obviously one cannot avoid mocking especially when dealing with resources external to your code base, yet I have hardly seen TDD-originated tests that mocked

nhaehnle 10y ago
> I find TDD helps me tackle bigger code-pieces where I just don't know how to start implementing. This made me think. There are many axes of software development, and aside from TDD/non-TDD axis, there's also the bottom-up vs. top-down axis. By top-down, I mean you start with a skeleton that provides an interface to the outside world, and the fill in the implementation details. Bottom-up, on the other hand, means you first write some routine that you know will be vital in some form or another, but without immediately seeing how it will be hooked into the interface to the outside world. Top-down has the advantage that you can have something runnable quickly, and it seems to me that TDD requires top-down development. But somehow, there have been times when I was working on a piece of code and it just flowed more naturally in a bottom-up manner. It has happened that I went for a day (and very rarely longer) working on tricky algorithmic code before I even tried to compile it for the first time. This is definitely something that I try to avoid when I can, it's just that sometimes it works out that way. And it is totally incompatible with the TDD way of doing things. How often this happens surely depends on the type of project you're working on. As usual with these things, it seems like TDD can be a useful inspiration, but it shouldn't be taken as dogma.
- wirrbel 10y ago
  This reminds me of https://twitter.com/marick/status/787402452848873472 https://twitter.com/marick/status/787402452848873472 I dont think writing Tests first makes you work top down or bottom up. If you want to work bottom-up (I like to work bottom up) you just start by writing tests for your bottom up functionality. And of course I don't want to impose TDD on others, but I would like others to try it out sincerely (recommending kent Becks book for this. Don't do it without guidance, many people who reject TDD after trying it out were doing some kind of Test-first method, but didn't get the benefit because they were not aware of stuff like get one test at a time to complete, etc.) --------- > shouldn't be taken as dogma. Life in software engineering becomes much more relaxed when you realize that every piece of advice and technology is in fact based on dogmas and is not based on sound empirical, statistically relevant evidence :-) (apart from the pure math part). It is just really really hard to study software quality in an objective way that satisfies scientific criteria. So we are kind of stuck with hearsay in IT So TDD is kind of dogmatic. So is OOP, or the rejection of gotos.

by wirrbel 10y ago

nhaehnle 10y ago

> I find TDD helps me tackle bigger code-pieces where I just don't know how to start implementing. This made me think. There are many axes of software development, and aside from TDD/non-TDD axis, there's also the bottom-up vs. top-down axis. By top-down, I mean you start with a skeleton that provides an interface to the outside world, and the fill in the implementation details. Bottom-up, on the other hand, means you first write some routine that you know will be vital in some form or another, but without immediately seeing how it will be hooked into the interface to the outside world. Top-down has the advantage that you can have something runnable quickly, and it seems to me that TDD requires top-down development. But somehow, there have been times when I was working on a piece of code and it just flowed more naturally in a bottom-up manner. It has happened that I went for a day (and very rarely longer) working on tricky algorithmic code before I even tried to compile it for the first time. This is definitely something that I try to avoid when I can, it's just that sometimes it works out that way. And it is totally incompatible with the TDD way of doing things. How often this happens surely depends on the type of project you're working on. As usual with these things, it seems like TDD can be a useful inspiration, but it shouldn't be taken as dogma.

wirrbel 10y ago
This reminds me of https://twitter.com/marick/status/787402452848873472 https://twitter.com/marick/status/787402452848873472 I dont think writing Tests first makes you work top down or bottom up. If you want to work bottom-up (I like to work bottom up) you just start by writing tests for your bottom up functionality. And of course I don't want to impose TDD on others, but I would like others to try it out sincerely (recommending kent Becks book for this. Don't do it without guidance, many people who reject TDD after trying it out were doing some kind of Test-first method, but didn't get the benefit because they were not aware of stuff like get one test at a time to complete, etc.) --------- > shouldn't be taken as dogma. Life in software engineering becomes much more relaxed when you realize that every piece of advice and technology is in fact based on dogmas and is not based on sound empirical, statistically relevant evidence :-) (apart from the pure math part). It is just really really hard to study software quality in an objective way that satisfies scientific criteria. So we are kind of stuck with hearsay in IT So TDD is kind of dogmatic. So is OOP, or the rejection of gotos.