Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Do you write tests before the implementation?

news.ycombinator.com

Post reply on HN
Print view View original

191–200 of 329 posts

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

#191

Post by woodrowbarlow »

i work on embedded development (lately, bare-metal firmware), and tooling is often lackluster. i have never worked on an embedded codebase with a unit-testing framework that's good enough that people actually use it. yes, i know some projects have managed it, but i have not had the pleasure of working on such a project.

with that said, if i'm about to tackle something that i _know_ is likely to have bugs, especially parser implementations, i will always start by isolating it into a separate file, mocking the dependencies, building test cases, and compiling and running natively on my workstation. i write test cases before i start the implementation, and continue adding to them throughout the process. when i'm satisfied, i copy-paste back into the real codebase and do light integration testing.

these tests ultimately get thrown away, but i genuinely feel that they help me arrive at a correct implementation more quickly than integration testing alone. honestly, it just helps me feel more confident that i'm not going to embarrass myself when the code hits the field. this technique doesn't really help me with business logic, unfortunately, because accurately mocking the dependencies is insurmountable.

tl;dr: i use TDD when i think it will save me time, but i don't keep the tests around because tooling sucks.

i'm posting this partially in the hopes that people have tooling advice for me.

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

#192

Post by tchaffee »

It's a tool like any other and I reach for it when tests will help me write code faster and at a higher level of quality. Which is pretty often with new code.

Also always before a refactor. Document all the existing states and input and output and I can refactor ruthlessly, seeing as soon as I break something.

Tests are also great documentation for how I intend my api to be used. A bunch of examples with input, output, and all the possible exceptions. The first thing I look for when trying to understand a code base are the tests.

When do I not write tests? When I'm in the flow and want to continue cranking out code, especially code that is rapidly changing because as I write I'm re-thinking the solution. Tests will come shortly after I am happy with a first prototype in this case. And they will often inform me what I got wrong in terms of how I would like my api consumed.

When did it fail me? There are cases when it's really difficult to write tests. For example, Jest uses jsdom, which as an emulator has limitations. Sometimes it is worth it to work around these limitations, sometimes not.

Sometimes a dependency is very difficult to mock. And so it's not worth the effort to write the test.

Tests add value, but like anything that adds value, there is a cost and you have to sometimes take a step back and decide how much value you'll get and when the costs have exceeded the value and it's time to abandon that tool.

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

#193

Post by tombert »

codeulike wrote: post #184
shantly wrote: post #179

Earlier quoted context omitted.

Everyone's in the confessional booth here admitting dogmatic test-first-test-everything's not so hot in practice, which is nice, but how long until it becomes safe to answer with anything other than some variation of "love testing, it's always great, I love tests, more is better" when asked how you feel about testing in interviews?

Oh of course you have to be enthusiastic about testing in interviews. Same as with agile!

Actually, for the interview for my current job (a pretty big corporation) they asked me about testing and I flatout said that I think testing has some benefit for some cases for , but I think the "100% CODE COVERAGE OMG TDD!!!" mentality is actually counter productive and makes code much harder to adapt.

I think they appreciated my honesty.

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

#194

Post by ElatedOwl »

christophilus wrote: post #126

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…

Spot on with cost, as with everything you have to be pragmatic.

Tests are great for:

* High risk items (large consequence when it goes wrong)

* Documentation

* Weird unintuitive things

We had a C# project recently that needs to detect changes between a DTOs properties. At implementation, all the comparisons would be done over value types, but if someone added a reference type that didn't properly implement equality this would silently fail (likely for months). Good case for adding a test that ensures the change detection works for all properties.

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

#195

Post by wyldfire »

uptownJimmy wrote: post #139

I am quite curious to know what percentage of working devs ever write tests at all. Because I don't think it's the majority, based on my own professional anecdata. But I've not yet been convinced that any of the various polls are very authoritative. So I dunno.

I write tests for each bugfix and feature with rare exception.

It's a great practice to have a regression test suite that you can use to run your code in a simple context. The unit test suite can catch all kinds of low-hanging fruit instead of waiting until you deploy the code to your target device or production service (or even the release cycle for those).

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

#197

Post by jlangr »

Sure, still, 20 years on. Not dogmatically so to reach some coverage goal, but anything with real logic, yes. I don't test-drive React components, for example (instead the goal is to get all real logic out of them).

Benefits--not pushing logic defects gives me more time to invest in other important stuff; I end up with tests that document all the intended behaviors of the stuff I'm working on (saves gobs of time otherwise blown trying to understand what code does so I can change it safely); I'm able to give a lot of attention to ensuring the design stays clean. Plus, it's enjoyable most of the time.

"They incur technical debt and bugs at the same rate as other code." Not at all true.

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

#198

Post by shhsshs »

jackweirdy wrote: post #44
Deradon wrote: post #21

Earlier quoted context omitted.

> Committing the red test and the fix to the test in two commits makes the bug and its fix easy to review. I've done this in the past. Then I started to use `git bisect` and having a red test somewhere in your commit-history is a killer for bisect. So now I tend to include both, the test and the bug-fix, within one commit.

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 value in reviewing them separately, because they are related and dependent changes.

Obviously if you view tests differently (eg. as a declaration of current behavior rather than intended behavior) then my argument dies.

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

#199

Post by swat535 »

christophilus wrote: post #126

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 if you make a typo, comment out a piece of code and forget to uncomment , etc?

I'd love to write less tests but don't know how to do it?

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

#200

Post by TheGrumpyBrit »

hombre_fatal wrote: post #152
corodra wrote: post #109

Earlier quoted context omitted.

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

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…

I fill the washing up bowl (or just the sink for the Americans) with hot water while my food is cooking. This has quite a few advantages:

1. It breaks the psychological barrier of actually starting the task of washing up, and because I'm doing other things, I don't feel like I'm waiting around for the water.

2. Dishes created during the cooking process can be cleaned quickly as they're used, without interrupting my flow. That means there's no daunting pile of dishes at the end of the meal.

3. When you finish eating, the water is already there ready for use. It's a simple dunk and wipe which is almost as quick as dumping the plates on the side.

Post reply on HN