Hacker News Reader

Comment by fogetti | Hacker News Reader

The thing is that most people don't understand that the code needs to be tested anyway. If you don't test it, you are just an idiot who has no proof that the code does what it claims to do.

Now because you have to test it anyway, you can just simply spend the same time writing a unit test instead of executing the code with manually configured non-repeatable test cycles, a.k.a clicking through the UI, or sending Postman requests, etc.

Also it's kind of selfish not to make something repeatable by others.

And as someone pointed out before me, unit tests are not about testing at all. It's a documentation about the system, and what it's supposed to do. Also it's the way to stop the next person who works on the code to ruin something by not knowing the business rules.

View on HN

> the code needs to be tested anyway. If you don't test it, you are just an idiot who has no proof that the code does what it claims to do

First, in most cases you're going to test your code manually anyway- whether you write unit tests or not. So writing unit tests is just in addition to the time already spent testing manually.

But most importantly, unit tests often do very little to prove "your code actually does what it claims to do". They prove you have tested some cases, that's all. In many occasions, the code under test doesn't even "claim" to do anything in particular: the claim is that you're delivering a feature, not pieces of code that behave as expected. All your code fragments can behave exactly as expected and still the feature might be broken, or miss implicit requirements, or ill conceived.

Finally, unit tests as documentation are disastrous, as they document only details of specific implementations, as opposed to the feature you're expected to deliver. Good comments are a hundred times better that tests in that respect.

> First, in most cases you're going to test your code manually anyway

Only if you are coding things with UI's. If you are creating a new API endpoint on some service or creating a new service or adding some new parts to a maths library there is no point in manual testing.

I feel a lot of the disagreements people have on development methodologies comes down to people working in different domains. When I do UI work I do mostly manual testing, when I do library work I do only unit testing.

Not all forms of testing consist of separate test suites like unit tests. Assertions, contracts, encoding constraints in elaborate type systems and having them checked at compile time are also ways of coding repeatable tests.

And if it's some poorly coded legacy application or something that's mostly wrapping a proprietary black box, working around other peoples bugs, and things like that then system or integration tests may be easier than attempting to mock a gordian knot's tangles.

Unit tests work best for properly encapsulated pieces of code, utility classes, libraries and such.

Yes, code must be tested. Line and branch coverage just don’t have the actual impact that some people claim it does. It is, however, better than nothing at all.

The arguments in the paper are anecdotal and I took them to be “question the cargo cult” which is a valuable thing to do. The author is merely encouraging you to think because “automated garbage is still garbage.”

Good read.

> If you don't test it, you are just an idiot who has no proof that the code does what it claims to do.

Does having tests make it any different? You would need to test those tests to make sure they are testing the right thing after all (ad infinity).

Untested tests are still a lot more useful than no tests, just like how an untested program (while probably worse than a tested program) is still usually better than no program at all.

Also, tests are actually subject to very basic testing in the red-green-refactor TDD cycle: they start out failing so you know that they actually test something when they start passing.

To add to this sentiment, tests also give teams confidence that is needed. It gives engineers confidence when developing new features because the test suite will break if you introduce a regression. It gives engineers confidence during deployment/CD.

While the tangible benefits of unit tests are very important, there are other intangible benefits that are equally important.

I’d say that confidence is a tangible factor.

The single most important reason to test your code seems to be that it allows you to refactor your code while ensuring it still meets the original outside expectations.

The author’s main gripe seems to be about tightly coupled tests that make refactoring larger systems more difficult, and about prioritizing meeting arbitrary metrics (lines of codes covered) rather that thinking critically about the actual benefits.

This is in line with his emphasis on integration tests determined by the business. I think that same thought process can be applied to internal components of code as well, and you can empirically determine the quality of your approach (roughly) by evaluating how often your tests change. If nearly every change breaks a test, that probably means they’re low value/too tightly coupled.

Excessive mocking seems to be the biggest source of evil in that regard.

What confidence do unit tests add that other kinds of tests do not?

The confusion here between unit testing and automated testing in general kind of illustrates the author’s point: we’ve become so obsessively focused on one kind of testing that we aren’t thinking critically about its alternatives (of which there are many others besides “no tests”).

Code needs to be tested anyway, but integration and functional tests can accomplish that more cost effectively.

Cannot tell you how many times I have seen projects with hundreds of green unit tests at 90% line coverage and yet regress on, miss important and obvious cases, or simply have never had their headline functionality.

Reply on news.ycombinator.com