If I'm changing a software that's in production: yes.
If I'm just messing around with a prototype I'm the only user of and don't yet know if it's going to be useful or go in production: no.
I do like to write tests that actually write tests though, see such patterns in django-dbdiff, django-responsediff, or cli2 (autotest function).
Ask HN: Do you write tests before the implementation?
61–70 of 329 posts
Re: Ask HN: Do you write tests before the implementation?
#62I've been writing software professional for 20 years and for much of that time I was very skeptical of testing. Even after I started writing tests it was several more years before I saw the value of writing tests first. I've moved to doing this more and more, especially when doing maintenance or bug fixes on the back-end. I still struggle with writing valuable tests on the front-end, apart from unit tests of easily e…
> If you write your test after making the code changes, its easier to have a bug in your test that makes it pass for the wrong reasons.
I see this a lot. I don't write tests first, but I always make sure my changes are properly covered by my assertions. For instance, when fixing a bug, I comment/undo my fix and make sure my test fails.
One could say I'm doing twice the work (fix, write test, comment out fix), but I find it easier than just writing the test first.
Re: Ask HN: Do you write tests before the implementation?
#63No. I tend to develop them in parallel.
Re: Ask HN: Do you write tests before the implementation?
#64No. I have always felt that TDD gives a false feeling of safety and satisfaction, and that it is mostly a waste of time that could be better spend optimizing and refactoring. Testing simple code is simple and therefore pretty much useless. Testing complicated code is complicated and therefore more likely to fail by making to few or to many assumptions in the test, or completely screwing up the test code itself.
A couple of takeaways from your post:
- knowing your code does what you expect is a _false_ sense of safety
- if something is simple, it is useless
- if something is complicated, it is useless
Re: Ask HN: Do you write tests before the implementation?
#65depends if its a critical component. For stuff that needs to be atomic and handles critical data then yeah. Otherwise less so.
TDD is really good for stuff that doesn't have a native test workflow (headless invisible stuff) as it can double up as a test harness, so for stuff like message queues its great. For user interfaces its pretty crap though because you already have a test harness and your eyes are much better at testing.
Re: Ask HN: Do you write tests before the implementation?
#66Never done this, and don't consider it practical. Code and interfaces (even internal ones) change rapidly for me when I'm starting a new project or adding new major functionality to the point that the tests I'd write at the beginning would become useless pretty quickly. I also believe that 100% test coverage (or numbers close to that) just isn't a useful goal, and is counterproductive from a maintenance perspective:…
That is how I used to work; then I got into finance and there are two things different with the work I did before that (web/desktop/app (or too long ago; there was no 'testing' in the 80s) the software I write now has to be certified/audited to some extent and I cannot change/repair production software on the fly. That could costs a lot of money for certain bugs. So now I tend to write tests for everything and that helps a lot.
Re: Ask HN: Do you write tests before the implementation?
#67No. And also 'do you write a test for everything?'. Also No. Tried it, ended up with too many tests. Quelle surprise. There is a time/money/cognitive cost to writing all those tests, they bring some benefit but usually not enough to cover the costs. I'm also going off the 'architect everything into a million pieces to make unit testing "easier"' approach. I heard someone saying that if you write a test and it never f…
Do you consider coverage an effective metric? I've got some code that has a test suite which is effectively a bunch of low level driver checks, plus a bunch of common example snippets and checks for eg empty inputs etc.
Coverage gives an idea of how many lines of code have been run, but obviously no guarantees of correctness for those specific lines (eg you can't detect a double negative).
It's worked well for me so far, since the important parts are (a) the hardware communication works and (b) users can process and output data in a way that is correct. No need to obsessively check the intermediate steps if the output is good.
Re: Ask HN: Do you write tests before the implementation?
#68The majority of the time, no. There are a couple of circumstances I often do, though. The first is when fixing a bug - writing the (red) regression test first forces me to pin down the exact issue and adds confidence that my test works. Committing the red test and the fix to the test in two commits makes the bug and its fix easy to review. The second is when I'm writing something high risk (particularly from a securi…
> Committing the red test and the fix to the test in two commits makes the bug and its fix easy to review.
I don't think this is compelling argument. Normally the test and the fix are looked at together and are already sufficiently separated in the code.
It makes more sense to me to use a single commit so the fix can be described in a single commit message, keeping the history clean.
Re: Ask HN: Do you write tests before the implementation?
#69The majority of the time, no. There are a couple of circumstances I often do, though. The first is when fixing a bug - writing the (red) regression test first forces me to pin down the exact issue and adds confidence that my test works. Committing the red test and the fix to the test in two commits makes the bug and its fix easy to review. The second is when I'm writing something high risk (particularly from a securi…
> Committing the red test and the fix to the test in two commits makes the bug and its fix easy to review. I don't think this is compelling argument. Normally the test and the fix are looked at together and are already sufficiently separated in the code. It makes more sense to me to use a single commit so the fix can be described in a single commit message, keeping the history clean.
Keeping it separate allows ensuring the test works easily: just revert the fix keeping only the patch for the test and make sure the test fails.
My workflow tend to be to keep them separate, and write a big description in the merge commit rather than the individual commits (those have a small description of the local change).
There's tradeoffs to both approach though, and as you mention, it's easier to keep track of the provenance of a fix in the git blame when it's unified in a single commit message.
Re: Ask HN: Do you write tests before the implementation?
#70I follow the Functional Core, Imperative Shell pattern. I do TDD on Core, especially on mission critical code. The Shell however have almost zero automated tests.
Thanks for that term, it sounds related to the style I prefer. Do you have any recommended references?
Try to watch Gary Bernhardt's "Boundaries" screencast (2012), if you haven't yet.
There are also some collection of links in github such as https://gist.github.com/kbilsted/abdc017858cad68c3e7926b0364....
The pattern articulated by Gary also best resonated my thoughts and experience in building software.