Comment by kelnos | Hacker News Reader

Comment by kelnos | Hacker News Reader

Parent Full thread

Never 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: test code is still code that has to be maintained in and of itself, and if it tests code that has a low risk of errors (or code where, if there are errors, those errors will bubble up to be caught by other kinds of testing), the ROI is too low for me.

After I've settled on interfaces and module boundaries, with a plausibly-working implementation, I'll start writing tests for the code with the highest risk of errors, and then work my way down as time permits. If I need to make large changes in code that doesn't yet have test coverage, and I'm worried about those changes causing regressions, I'll write some tests before making the changes.

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.

If I worked on software like that, I would almost certainly write more tests. But still not up-front.

Agreed, and the kind of software you’re working on is a part of this conversation that often gets left out and leads to people talking last each other. I work in cryptography, and our work needs an exceptionally high level of testing to catch subtle bugs. I used to work in games and I didn’t see the same value out of tests. Different industries require different practices.

>So now I tend to write tests for everything and that helps a lot.

Isn't that a separate issue from writing the tests before the implementation?

Yes, and I do both.

What "other kinds of testing" do you do instead then? How do you make sure the code is testable by those other tests?

Often people fall back on manual testing, which is often slow, unreliable and incomplete. And certain things might not even be testable if the system hasn't been designed to allow it.

Functional and integration testing, mostly.

I guess I'm assuming we're talking about unit testing specifically here, so I'm considering functional and integration testing as separate items.

Manual testing is terrible. I'll occasionally engage in that, but only as an extremely-short-term measure when I'm (again) not convinced my interfaces are stable enough yet to write unit tests.

I've been asked to literally test that values are incremented. Like, does ++ add 1 to the value in C, just to be safe, for the sake of 100% coverage.

I've seen tests that essentially look like that, and tests that, when you really look at it, pretty much just test the testing framework and mocking library and don't really exercise application code. It's infuriatingly useless.

Reply on news.ycombinator.com