No, because I'm always under pressure to show something on a screen as early as possible, but I really wish I did.
Ask HN: Do you write tests before the implementation?
31–40 of 329 posts
Re: Ask HN: Do you write tests before the implementation?
#32No, although sometimes I do wish I were working on problems that are so simple to test.
Re: Ask HN: Do you write tests before the implementation?
#33No, in fact, we don’t use coded tests at all, deliverables are tested by the product owner(s). On the code level, we hardly see bugs, not even when refactoring. I often wonder if it is luck or expertise, and whether we would benefit from writing tests.
Re: Ask HN: Do you write tests before the implementation?
#34I 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.
Re: Ask HN: Do you write tests before the implementation?
#35Only when fixing a bug (job done when tests pass) or reworking something that I believe isn't well tested (job done when I'm happy with the refactor & tests still pass).
Re: Ask HN: Do you write tests before the implementation?
#36No, in fact, we don’t use coded tests at all, deliverables are tested by the product owner(s). On the code level, we hardly see bugs, not even when refactoring. I often wonder if it is luck or expertise, and whether we would benefit from writing tests.
Maybe you hardly see bugs because you don't test for them.
Re: Ask HN: Do you write tests before the implementation?
#37When I contemplate how I'm going to implement it and it starts to look overwhelming and tedious then I go and write some tests.
Other situations are coming just from experience: you know that some part will have a lot of special cases, so you implement a test as soon as you think of the next special case.
Re: Ask HN: Do you write tests before the implementation?
#38No, in fact, we don’t use coded tests at all, deliverables are tested by the product owner(s). On the code level, we hardly see bugs, not even when refactoring. I often wonder if it is luck or expertise, and whether we would benefit from writing tests.
I used to wonder the same thing, until I inherited a project with tests.
The tests never caught a bug for the first 3 years. Got in the way a lot though.
Then they finally caught 1.
Not worth it.
Re: Ask HN: Do you write tests before the implementation?
#39Only when I'm sure the requirements won't change while I'm writing the implementation. Which is 5%-10% of the time at best.
Re: Ask HN: Do you write tests before the implementation?
#40TDD works best at the interface where there is the lowest likelihood of API churn.
Writing a test for something an MP3 ID tag parser is a good case for TDD with unit tests. It’s pretty clear what the interface is, you just need to get the right answer, and you end up with a true unit test.
Doing TDD with a large new greenfield project is harder. Unless you have a track record of getting architecture right first time, individual tests will have to be rewritten as you rethink your model, which wastes a lot of energy. Far better is to test right at the outermost boundary of your code that isn’t in-question: for example a command line invocation of your tool doing some real world example. These typically turn into integration or end to end tests.
I tend to then let unit tests appear in stable (stable as in the design has settled) code as they are needed. For example, a bug report would result in a unit test to exhibit the bug and to put a fixed point on neighboring code, and then in the same commit you can fix the bug. Now you have a unit test too.
One important point to add is that while I reserve the right to claim to be quite good at some parts of my career, I’m kind of a mediocre software engineer, and I think I’m ok with that. The times in my career when I’ve really gotten myself in a bind have been where I’ve assumed my initial design was the right one and built my architecture up piece by piece — with included unit tests — only to find that once I’d built and climbed my monumental construction, I realized all I really needed was a quick wooden ladder to get up to the next level which itself is loaded with all kinds of new problems I hadn’t even thought of.
If you solve each level of a problem by building a beautiful polished work of art at each stage you risk having to throw it away if you made a wrong assumption, and at best, waste a lot of time.
Don’t overthink things. Get something working first. If you need a test to drive that process so be it, but that doesn’t mean it needs to be anything fancy or commit worthy.