Hacker News Reader

Comment by fragbait65 | Hacker News Reader

I think it's a failure to ever believe that unit tests provide any correctness proof. The only thing you achieve with unit tests is to prove that you are still bug for bug compatible when changing your code.

I think experience is needed to know when to unit test. Some code might not need any tests at all while other code might need quite a lot of tests.

My personal experience, for the code bases I work on, shows that for those code bases mocking is usually not beneficial, we find more problems with integration testing and fuzzing. That holds for those code bases, it might very well be different for other code bases, and here's where experience comes in again...

View on HN

> The only thing you achieve with unit tests is to prove that you are still bug for bug compatible when changing your code.

People love to ignore how fucking awful code is when you aren't forced to write unit tests.

Unit tests before you write code help you code, they provide a tight feedback loop, they force or at least encourage modularity to be testable.

Adding tests to my code after writing it forces me to challenge assumptions and frequently requires refactoring to improve the code along with testability. It also documents my intent better than comments can and often gives consumers valuable example usage code.

Yes it's a trade off and sometimes overkill but that's why 100% coverage is a stupid goal. You should always evaluate RoI of the tests you're writing.

Integration and end to end testing is much the same, they're simply different grain sizes, we need all of them to be effective.

The biggest mistake that happens with testing is assuming it's all about correctness, doing so is why we have 100% coverage people around, they're equating 100% coverage with 100% correct which is just a wrong conclusion.

Quite iteration/feedback loop is a big plus for sure

I used to do TDD, I found that it didn't work that well for me.

I still think that the code base you work on dictates how you should be testing. It also dictates which testing strategy I use.

I test for different things when writing C than I do when I write Python for example. My testing strategy is different if I write a networked C application compared to if I write a Ruby on Rails app.

Also the tools I have available to me when writing the code dictates how I will test, which is tied into which language I write in.

And I really disagree that code has to be awful because you are not forced to write unit tests. I work with a team of 4 other experienced and responsible programmers. We actually don't have to have rules that force us to do anything. We are responsible enough and experienced enough to know what to do and when to do it.

40 - 50 % of our code base doesn't have a single unit test, because it doesn't have to have any. Are we infallible, no. Does mistakes happen? Yes. Do we sometimes go back and add unit tests to code that we thought didn't need any. Yes, it happens.

Would unit tests have saved us sometimes? Yes. If it would have, then we are responsible and go back and add that test.

I think the point was more that many people can’t write unit tests because their code is so shoddy that it’s basically impossible to do so.

It sounds like you and I share a similar methodology. I don’t write unit tests for all my code. In fact if I had to guess, I’d say I generally test less than 25%.

But I do write all my code such that it’s capable of having unit tests written for it.

In many codebases that’s just not possible. The developers have spent all their time writing and none of their time thinking. It’s one big yarn ball that’s impossible to write unit tests for. For these people, forcing them to write tests up front would have resulted in a much cleaner code base.

I do enjoy TDD, in that it makes it easier for me to ensure that I implement everything I need.

I completely agree that it's not always necessary, but I definitely find it a useful tool.

That being said, TDD with ML applications is a bunch trickier, as you'll normally have functions/classes which take an unfathomably looooooonnnnngggg time to run.

Well, I can agree with that!

Chances are that your code base will be untestable, at least for unit testing, if unit testing where not considered at all when writing it.

40-50% is perfectly acceptable for your team by the sounds of it. In other teams with varying degrees of experience and skill things are a bit more wild.

The fact that you can add tests means your code is at least somewhat scaffholdable and that is the important part for testability.

For the record I do TDD maybe 20% of the time, I mostly just use it in tough problems where I don't know what to do next.

It's a tool, not a goal.

> The only thing you achieve with unit tests is to prove that you are still bug for bug compatible when changing your code.

If your tests are ensuring buggy behavior, then... you're writing your tests wrong?

What are you even trying to say with this? I've never once seen a unit test intended to enforce a bug...?

If you have a web API that returns a 200 OK with a JSON object with a missing entry when an item is not found, instead of a 404 error, then you have a bug in your API.

But you cannot allow it to change because your users are relying on the existing behavior.

And this is the case for, what, maybe 0.1% of unit tests?

And you're using that... to justify that the "only" thing unit tests achieve is maintain bugs? Although in any case, this is no longer a bug, it's part of your spec now.

But regardless, what about the other 99%+ of unit tests that are enforcing correct behavior...?

Your argument is like saying that food is bad because people occasionally get food poisoning.

Reply on news.ycombinator.com