Live data from Hacker News

Ask HN: Do you write tests before the implementation?

news.ycombinator.com

221–230 of 329 posts

Re: Ask HN: Do you write tests before the implementation?

#221
Acceptance tests, yes. Nothing puts my mind at ease like knowing that when I feel I am done coding, I can follow a list of actions on a spreadsheet and call it done when every row is green.

Integration tests, sometimes. Depending on the complexity of the system, I might skip this part. If it is a collaborative work then integration tests are (in my view) mandatory for ensuring that everyone’s code plays nice with everyone else’s.

Unit tests, almost never. Unless it’s something absolutely production critical, pull-your-hair-out-at-5-on-a-Friday kind of feature, it’s usually not worth the extra time putting unit tests together.

Re: Ask HN: Do you write tests before the implementation?

#222

No. Tests are like any other code. They incur technical debt and bugs at the same rate as other code. They also introduce friction to the development process. As your test suite grows, your dev process often begins to slow down unless you apply additional work to grease the wheels, which is yet another often unmeasured cost of testing in this fashion. So, in short, I view tests as a super useful, but over-applied too…

Maybe you can help me understand this. Since you don't write as many tests, that means you're not actually testing all your code branches because tests incur technical debt after all. So does this mean you test every single branch manually? just don't bother with it at all? Do you just have a few integration tests and they break and you spend a good chunk of time figuring out which logical branch broke? What happens…

I write tests when I know the answers before to some complicated code.

A good example of this is writing some code to tell if a point is inside a triangle or not. Setting up the test case is easy with three points for the triangle, a point or two inside, points outside, etc... Writing the code is simple enough, but possibly prone to flipping a sign for a slope, or maybe translating the equation wrong.

If I'm writing a web app, I just don't bother to write them before hand. I mostly code until I get what I want and then write the test. I think of this as "nailing it in place". I want to make sure through the test that this code continues to produce what I expect. I'll write as many tests as I feel are necessary but probably not explore every branch.

Re: Ask HN: Do you write tests before the implementation?

#223
post #167
post #117

Earlier quoted context omitted.

At the risk of being serious for a moment, saying "please" and "thank you" are two of the lowest effort, highest reward, and plainly decent things you can do as a human.

Muh. It's OK to be one of those endless-pleasers-and-thankers, that's how you are... but stop being so fucking condescending about it! ...some of us "other kind" of people actually consider excessive politeness as offensive because it wastes time and pollutes conversations and after a certain we'll start actually being offensive with people like you, and you'll just stare amazed at how horrible people we can be! When…

Thanks for your input nnq. Please tell us more. Thanks!

Re: Ask HN: Do you write tests before the implementation?

#224

Earlier quoted context omitted.

Enlighten me, why?

Not sure I'd call it a 'bad bad practice' for a user to do it voluntarily, but it's unnecessary. I think the above commenter is thinking about the requirement a user to change a password on a timed basis. There's been a good bit of research done in this area, and the consensus is that it just causes most people to stick a number at the end of their password anyway, making the policy completely worthless at best, but…

Yeah I think it does more harm than good for sure.

Re: Ask HN: Do you write tests before the implementation?

#225

Yeah. I also floss every day, clean up the kitchen as I cook, keep off-site backups of my personal data, call my mother regularly to thank her for raising me, read the terms and conditions to online services, keep an up-to-date to-do list, and change all my passwords once a month.

Suddenly I feel very lonely for the fact I do actually clean the kitchen during and right after cooking...

You're not alone. It's a really satisfying practice, and for me it's almost part of the recipe. I've learned not to 'chip in' too much when others are cooking a meal though.

(I've just realized that's basically what I'd say about TDD too)

Re: Ask HN: Do you write tests before the implementation?

#226
I write both client-side and server-side code.

In server-side, almost all code is atomic, very functional and is very easy to cover with tests, on different levels. I start with several unit tests before implementation and then add a new test for any bug.

The client, however, is a completely different story. It's a thick game client, and through my career I honestly tried adopting TDD for it - but the domain itself is very unwelcoming to this approach. The tests were very brittle, with a ton of time spend to set them up, and didn't catch any significant bugs. In the end, I abandoned trying to write tests for it altogether - at least I'll be able to write my own, functional and test-driven game engine, to begin with.

Re: Ask HN: Do you write tests before the implementation?

#227
Not always before, but always eventually and usually once I’m done with “exploration”. Testing done right should be a time saver in the long run! I think many people are turned off by testing and especially unit testing because it ends up being difficult and maintenance is more of a pain than it’s worth. There are many good strategies to make it easier that in my experience have yet to be well adopted:

https://m.youtube.com/watch?v=URSWYvyc42M https://www.destroyallsoftware.com/talks/boundaries

Re: Ask HN: Do you write tests before the implementation?

#228

Earlier quoted context omitted.

It's a weird quirk of the brain how easy it is to wait until the food hardens onto the cooking utensils before cleaning it (sometimes needing a hammer and chisel to remove it) rather than just rinsing it off immediately with water. Yet, despite knowing this, picking the former route every damn time anyways. If you're like this, try putting on some small bluetooth headphones. Now cleaning the dishes just becomes a way…

It's weird... I'm a real lazy person. I do the dishes immediately because of this reason, it's faster and easier. I absolutely hate doing crusty dishes. So, I'm just confused in general why people wait. Its straight up less effort to do it sooner than later.

Do you have kids? I always had the same opinion until I had my daughter, and then all of a sudden there is a 2 year old who needs supervision and it becomes easier to clean up after bed time.

Re: Ask HN: Do you write tests before the implementation?

#229

Earlier quoted context omitted.

A tip I learned is to commit the failing test but mark it as an expected failure, if your test framework supports that. That way you can commit the test, bisect works, and the test begins "failing" when the bug is really fixed, and you can commit the fix as well as a one-line change to amend the test from being failure-expected to just a normal test.

I see a test as a declaration of intended outcome. By writing a test to expect an intentional failure (say you have a bug in a divide: “int -> int -> Maybe int” function that causes it to return 0 when you divide by 0 instead of “None”) you are declaring that is actually intentional behavior. So I would never write a test like this - I think I would prefer committing the fix and the new test at once. I don’t see the…

Keep in mind the test is written with the correct behaviour and annotated to be failing — in a hypothetical language and framework your test would be

@failing testDivZero() { assertEquals(None, div(1, 0)) }

This expresses both the intent and the reality

Re: Ask HN: Do you write tests before the implementation?

#230

No. Tests are like any other code. They incur technical debt and bugs at the same rate as other code. They also introduce friction to the development process. As your test suite grows, your dev process often begins to slow down unless you apply additional work to grease the wheels, which is yet another often unmeasured cost of testing in this fashion. So, in short, I view tests as a super useful, but over-applied too…

Maybe you can help me understand this. Since you don't write as many tests, that means you're not actually testing all your code branches because tests incur technical debt after all. So does this mean you test every single branch manually? just don't bother with it at all? Do you just have a few integration tests and they break and you spend a good chunk of time figuring out which logical branch broke? What happens…

Yeah, as soon as code has more than two "real" branches, I don't trust myself to manually test them all. One of them will be broken quickly if I keep hacking in a particular branch. (This is, secretly, also an argument for writing code in sufficient generality to avoid this phenomenon in the first place.)

I also never trust a test that passes the first time I run it. I am both terrible at writing correct code, and completely normal in that regard.

Post reply on HN