3 ms·

Thankfully we don't have to. Hillel Wayne links to a few of the studies that have been done on TDD [0]. It doesn't have a conclusive effect on error rates in so

Thankfully we don't have to. Hillel Wayne links to a few of the studies that have been done on TDD [0]. It doesn't have a conclusive effect on error rates in software. While I do write tests before I write code, more so in a dynamic language without a strong, static type system; it appears that there isn't any correlation to a reduced number of bugs. But I still do it. And I think that's because that while I may prevent a few obvious errors with the practice the benefit I get is from the informal, automated specifications of the units of a module that I'm building. I also get the benefit of a continuous refactor cycle. Less experienced developers wonder how I write clean, simple code: I refactor, a lot, all the time, because I have tests checking my code. If it's functional correctness we're after TDD is only one, small, piece of the puzzle. A strong, formal specification will go a lot further to ensuring correctness than fifty more unit tests. [0] https://www.hillelwayne.com/talks/what-we-know-we-dont-know/ https://www.hillelwayne.com/talks/what-we-know-we-dont-know/

Cthulhu_ 7y ago
I haven't written tests as part of my regular workflow in... years now, but one of my earlier mind blown / level up as a developer was when I wrote tests, which made it required that my code actually had to be clean and conform to a load of best practices that weren't in my mind's eye yet. The other day I was doing a part of Go Blueprints which touched upon TDD; one thing it highlighted was that if you use TDD you should only write until your test is green, no more - this (supposedly) avoids you writing too much code. It has some merits. I'll need to do a lot more TDD and co to actually see it though.
omarhaneef 7y ago
Don't you think that if tests are effective, they may let you go faster? To put it another way, it is not surprising that error rates are similar since, presumably, you keep coding till you produce an error, fix it and then repeat. The question is how much error free code you wrote between the errors. If testing -- or any technique for that matter, like relaxing, jogging, discussing, planning -- reduces errors, it will manifest as more functionality per error.
- barrkel 7y ago
  "Effective tests" are a bit like the sufficiently smart compiler, or No true Scotsman fallacy. Tests either take a long time to run because they're integration tests in disguise, or they mock and stub module boundaries and are an impediment to design refactoring because lots of tests are invalidated. I tend towards favouring unit tests for leaf modules, especially those that get reused a lot, and fewer but rich (and slow) integration tests for a whole stack of functionality, end to end, where the test doesn't need much rewriting even if the design changes substantially. Unit testing everything usually undertests the composition of modules. You can fool yourself (especially using code coverage as a metric) that unit testing makes it easier to have complete testing, but actually the space of code under composition of units is much larger, and unit tests don't really test that at all.
  - Huggernaut 7y ago
    Depending on your use of the term "unit" and "integration" (testing taxonomy is bad), I tend to do the opposite, but with the addition of acceptance (user feature testing) to tie the whole thing together. By this I mean that I unit test (as driven out by Discovery Testing i.e mocking collaborators) down the dependency graph until I hit a leaf node, which I will integration test against real external systems or black box unit test if the logic is self contained. This sort of drives out a world where slow tests are kept to the leaf components, or the e2e acceptance, and everything else is quick with confidence in all the paths. It certainly does lead to a world where refactoring is more costly because of the burden of these mocks but this isn't trying to follow Chicago TDD where the refactor step is part of the cycle, instead looking like London TDD where the testing puts pressure on the design itself, so refactors are far less common.
    - ed_elliott_asc 7y ago
      > (testing taxonomy is bad) So true, it is terrible! What I say is: Unit tests - small tests that show the intent of one line of code or small set of lines, what the developer thought it was meant to do - can't prove correctness of an entire process Integration tests - test one specific process works (login success, login fail, etc.) starts to prove correctness of one part of an application Acceptance tests - larger, test that processes interact together and prove that multiple processes work Production tests - (roll out to x users and monitor or something similar) - prove that the entire application works, in production. Tests go from: Small to large, fast to slow, no risk to complete risk

Cthulhu_ 7y ago

I haven't written tests as part of my regular workflow in... years now, but one of my earlier mind blown / level up as a developer was when I wrote tests, which made it required that my code actually had to be clean and conform to a load of best practices that weren't in my mind's eye yet. The other day I was doing a part of Go Blueprints which touched upon TDD; one thing it highlighted was that if you use TDD you should only write until your test is green, no more - this (supposedly) avoids you writing too much code. It has some merits. I'll need to do a lot more TDD and co to actually see it though.

omarhaneef 7y ago

Don't you think that if tests are effective, they may let you go faster? To put it another way, it is not surprising that error rates are similar since, presumably, you keep coding till you produce an error, fix it and then repeat. The question is how much error free code you wrote between the errors. If testing -- or any technique for that matter, like relaxing, jogging, discussing, planning -- reduces errors, it will manifest as more functionality per error.

barrkel 7y ago
"Effective tests" are a bit like the sufficiently smart compiler, or No true Scotsman fallacy. Tests either take a long time to run because they're integration tests in disguise, or they mock and stub module boundaries and are an impediment to design refactoring because lots of tests are invalidated. I tend towards favouring unit tests for leaf modules, especially those that get reused a lot, and fewer but rich (and slow) integration tests for a whole stack of functionality, end to end, where the test doesn't need much rewriting even if the design changes substantially. Unit testing everything usually undertests the composition of modules. You can fool yourself (especially using code coverage as a metric) that unit testing makes it easier to have complete testing, but actually the space of code under composition of units is much larger, and unit tests don't really test that at all.
- Huggernaut 7y ago
  Depending on your use of the term "unit" and "integration" (testing taxonomy is bad), I tend to do the opposite, but with the addition of acceptance (user feature testing) to tie the whole thing together. By this I mean that I unit test (as driven out by Discovery Testing i.e mocking collaborators) down the dependency graph until I hit a leaf node, which I will integration test against real external systems or black box unit test if the logic is self contained. This sort of drives out a world where slow tests are kept to the leaf components, or the e2e acceptance, and everything else is quick with confidence in all the paths. It certainly does lead to a world where refactoring is more costly because of the burden of these mocks but this isn't trying to follow Chicago TDD where the refactor step is part of the cycle, instead looking like London TDD where the testing puts pressure on the design itself, so refactors are far less common.
  - ed_elliott_asc 7y ago
    > (testing taxonomy is bad) So true, it is terrible! What I say is: Unit tests - small tests that show the intent of one line of code or small set of lines, what the developer thought it was meant to do - can't prove correctness of an entire process Integration tests - test one specific process works (login success, login fail, etc.) starts to prove correctness of one part of an application Acceptance tests - larger, test that processes interact together and prove that multiple processes work Production tests - (roll out to x users and monitor or something similar) - prove that the entire application works, in production. Tests go from: Small to large, fast to slow, no risk to complete risk