Hacker News Reader

Comment by morgante | Hacker News Reader

I'm not sure why the author attempts to redefine "unit testing" at a higher level of testing. It seems pretty well-accepted that most API tests are, in fact, integration tests. There's no need to use the term "unit test" in this case.

Otherwise, I quite agree. I don't write unit tests. A complete set of integration tests gives me about 80% confidence in the correctness of code. Unit tests might bump that up to 90%, but you'll never get to 100% from testing alone and the substantial effort necessary to get there just isn't worth it.

Testing follows the classic 80/20 rule. Integration tests only take 20% of the effort required for full unit test coverage, but can give you the bulk (80%) of the benefits. For all but the most sensitive of applications, it's probably not worth it to put in the additional 80% effort for a mere 20% gain.

View on HN

I am not arguing against the integration test point, but I do see a value in unit tests.

When I write/modify a piece of code, I of course must see so it works. I run the new code, feed in some data and see the results.

If I separate UI and backend/model, I can just write code that feed data to the model to see so it works (instead of doing it ad hoc, by hand). Then I save that as a unit test. It is part of the documentation too (a use case).

Cheap, easy and with good value for effort. (Depending on problem domain.)

Edit: I can see where the "test induced design damage" comes from, mocking is bad, but I think code also often get better when it is made testable (dep injection, think about fan out/in, etc)

It sounds like you're writing functional or integration tests, not method-by-method unit tests.

That's all easily accomplished with integration tests. Generally, any good architecture makes a separation between the UI and the backend. You should absolutely have integration tests for the backend by itself, but I don't think it is necessary to get to the level of unit tests (testing every single method used in the backend).

Personally, I try to separate the backend into its own separate service. The first step is to write tests against the API for that service, and then to make those tests pass by completing the service. This has the added benefit of letting the tests serve as a spec documentation, which makes it very easy to farm out implementation to employees or contractors.

Sorry, missed the answer. How can quick tests to see that API (and internal stuff) work not be Unit tests? :-)

But sure, it is a discussion of what we should call the useful tests. I have (also) burned out on > 80% coverage for tests when the specifications aren't written in stone.

Reply on news.ycombinator.com