Hacker News Reader

> I rarely find unit tests catch any actual bugs

What kind of code are you writing? Sure, a Spring service that just integrates a bunch of other services is hard to test due to mocks galore, but any dense logic blocks should be moved to standalone, testable classes.

For my math libraries, Fibonacci compression algos, etc, I find the hundreds of unit tests invaluable. Add to that, in tools like SBT, "sbt ~testOnly com.MyTest" will rerun tests on every change, giving me feedback in under a second, rather than the whole dev/test cycle of save/restart_server/click_on_UI. Write unit tests for the tricky bits that will benefit from them.

Yes, unit tests are ideal for stuff like math libraries. A math function has a specification which will stay fixed for centuries, which you can easily test with a unit test and in the mean while you can change the implementation to optimize performance.

But this is not what coding looks like for the average IT job, which is more about routing data flows between a database and a web service endpoint or building web gui's. That code can also be unit tested and it can certainly have some benefit to do that while writing new code, because as other have said, it promotes a good coding style with small blocks of testable code, can serve as documentation etc. But for catching regressions, unit tests have much less value there. These unit tests will typically test only a few lines of business logic where database and web service calls have been mocked away. And chances are that the code will only need to be changed again when some requirement has changed. Which means that your unit test needs to be changed as well, or even completely rewritten. If you're not careful, maintaining your unit test suite can take you more time than updating the business logic. Which doesn't mean that you shouldn't write any tests at all, but for catching regressions, integration and system tests will have much more value.

I'm a big fan of tests but have to agree with you. The average IT job is just CRUD or all the logic is in a stored procedure.

> all the logic is in a stored procedure

If you don't have unit tests for your stored procedures, how do you know any changes to them actually work? Run it on production data?

These are known algorithms you're talking about, the one place where unit tests actually consistently make sense. I'm not writing a math library, however. I'm writing APIs and web GUIs. We have an immense amount of business logic and we do unit test a lot of it, but as I mentioned above, those unit tests hardly ever catch any bugs and they take a lot of time to maintain. Every time there's a change in the logic, the tests have to be updated. 999/1000 times, when a unit test fails after a chance it's because it needs to be updated, not because there is a bug. Keeping up with those updates is simply not worth the time to catch one bug per year. Neither is writing new unit tests in these areas. Writing them for well-defined algorithms with a limited (or at least definable) set of known inputs and outputs, as I mentioned in my original reply, is still useful. Other types of testing that our developers could do to make sure the code is high quality are much more useful of course and therefore preferred because they actually help make the codebase better rather than creating the illusion of doing so as unit tests often do.

I don't use tests, and I find that when I need to make a change to some code that has, say, four or five different paths through the logic, a lot of times one of the paths will break. Testing all of the paths manually each time there is a change is incredibly tedious and time-consuming. I feel like if I had unit tests I would be able to just see instantly if anything was broken. But, I never can seem to find the time to write them...

> 999/1000 times

Gosh I love made-up numbers, don't you? I've had unit tests just these past few weeks catch bugs within our Redux logic flows, from Action Creators. We have to ship this app next week. Guess what would've happened if I hadn't written those tests?

Now, the thing is I actually agree with you; as does nearly everyone who's replied to you here: Unit tests are not a panacea, and they really shine when as a part of a full test-suite that covers interaction, functionality, integration and more. Of course, this is why any decent testing framework gives you those abilities as well... You're disagreeing with an argument that no-one has put forward, from what I can see.

This is also true in my experience when writing unit tests that are forced as part of the process. I've seen situations where unit tests were prioritized over glaring critical bugs. Sure in an ideal world you would do both but life is a trade-off and there are some people who when faced with a failing project cling to conventional wisdom fanatically instead facing their fear and thinking clearly, because at the end of the day its easier writing unit tests instead of fixing the critical bugs that you haven't been able to solve for the past year.

Sometimes you need to throw the baby out with the bathwater in order to realize that the baby was never in the bathtub, that it had left the bathtub a long time ago.

I agree most of the tests one writes before integration only capture the most trivial stuff that seldom breaks. Now I write tests after a bug or some weird condition arise as not to fall in that trap twice. Capturing bugs as test before solving them also ensure the fix is proper and doesn't regress other stuff. The real issue is to make sure if anything happens, tests can replicate that