Live data from Hacker News

Unit Tests Considered Harmful

shaiyallin.com

21–30 of 76 posts

Re: Unit Tests Considered Harmful

#21
post #4

If your not Dijkstra then using title like that negatively affects people's perception of your post.

“Considered Harmful” considered harmful? :)

“Considered Harmful” Essays Considered Harmful, Eric A. Meyer, 28 December 2002:

https://meyerweb.com/eric/comment/chech.html

Re: Unit Tests Considered Harmful

#22
post #9

It keeps coming back to the same stupid erosion of paradigms. Once upon a time, some developers that were smarter than others started testing their code. They described ways to test smaller parts of large software systems separately before being integrated together. For instance "parameter testing" (to validate component subprograms against their specification) and "assembly testing" (for parts put together)[^1] As a…

Studies on TDD has failed to show a benefit over writing tests after the fact. The only factor that seems to matter is writing tests , the more tests the better. If you can write your code so it's amenable to more testing, or such that it requires fewer tests because it's simpler/has fewer cases to handle, great. If you have a framework that can generate tests (fuzzing, property-based testing), awesome.

Yeah, that's something I've been promoting for years. I don't care whether you write tests first or last, as long as you eventually get into a feedback loop of coding and verifying your code, quality will improve.

The same goes for customer specs. Just build a thing and verify if this is right.

Rinse, repeat. Progress is the only metric.

Re: Unit Tests Considered Harmful

#23
> My approach prefers extracting IO operations to adapters, testing them separately, then using reliable fakes to test the bulk of the system’s behavior from the outside

...which is exactly a unit test.

If you want to talk about "functional core, imperative shell" and its implications for tests, then do _that_. Writing clickbaity titles that directly contradict the content of your short blog post itself isn't a great way to foster nuanced discussion.

Re: Unit Tests Considered Harmful

#24
Automated tests are great, the problem described is over-reliance on mocking. Mocking should only be used for dependencies which have non-deterministic behavior or where it is otherwise impractical to use the real implementation.

Re: Unit Tests Considered Harmful

#25
post #2

The target audience for unit tests is not the client, it is the developer. Unit tests allow you to change code with more confidence. 100% code coverage is not a useful aim, you should aim for 100% confidence in your code. Unit tests can also function as example code, that can't get out of date, since then the tests will fail. Testing for quality assurance is a different thing, usually called acceptance testing and so…

A few years ago, I got tired of my company talking about plans to upgrade our main app from Python 2 to Python 3, until one weekend I just did it. The tests caught a million little changes that I worked through until everything passed. Come Monday, we were on Python 3 and I took a couple workdays off to play video games.

I wouldn’t have dared even start if I didn’t have confidence in our test suite.

Re: Unit Tests Considered Harmful

#26
I think whats more harmful than unit tests are code coverage metrics for unit tests that devs feel compelled or are required to achieve. The easiest way to achieve code coverage goals for tests is to write lots of small tests that test individual methods, but test very little of the interaction between them.

I feel that the goal of unit testing should be to test the largest unit possible without requiring external dependencies. In the language of domain driven design, this means to test the domain model. If you can get extensive coverage of the domain model as a whole, system tests can be used to test the complete system.

Alas, I have seen very few software systems with high quality domain models. It is not an easy thing to achieve.

Re: Unit Tests Considered Harmful

#27
post #2

The target audience for unit tests is not the client, it is the developer. Unit tests allow you to change code with more confidence. 100% code coverage is not a useful aim, you should aim for 100% confidence in your code. Unit tests can also function as example code, that can't get out of date, since then the tests will fail. Testing for quality assurance is a different thing, usually called acceptance testing and so…

As the author points out, "What constitutes a unit? Is it a function? A class?"

If you test to a function, or a class, then your tests imply that function or class must be present, with that specific API.

In my experience, most people write unit tests for internal implementation details that are irrelevant to the business domain. They end up inhibiting code change rather than encouraging change, because anything changes often require re-evaluating each failing test to see if it was meaningful in the first place - and if 100s of tests are no longer meaningful, it's easy to skip the couple of tests which are true regression tests.

As the author writes, full end-to-end tests "are often slow, cumbersome, hard to debug and tend to be flaky."

Instead, find the internal interfaces which tied to the business logic ("something that delivers value to a paying client"), and write the tests to that. You can use unit test frameworks for that sort of functional testing.

Re: Unit Tests Considered Harmful

#28
post #2

The target audience for unit tests is not the client, it is the developer. Unit tests allow you to change code with more confidence. 100% code coverage is not a useful aim, you should aim for 100% confidence in your code. Unit tests can also function as example code, that can't get out of date, since then the tests will fail. Testing for quality assurance is a different thing, usually called acceptance testing and so…

Agree. The "what about the client" trope is a complete non-argument. If unit tests make code better, the client maybe wants that. The argument should purely be based on if they are helpful.

I'll take it a step further than this. It doesn't matter if the client wants unit tests or not. If the developer has been hired to do the job, it's going to be up to that developer whether or not they feel unit tests will make the code better. If they do, they should do them. If they don't, they shouldn't.

Caring about the client's opinions re: unit tests is a little like caring about their opinion re: the interior color of your vehicle. Sure we can talk about it if it comes up over a beer some Friday evening but we're certainly not going to change anything based on the conversation.

Post reply on HN