Hacker News Reader

Comment by the_arun | Hacker News Reader

Unit Tests = The assurance/confidence that you get, if something changes logic, this test will break & you will know it. Aside from just limiting bugs - this is more powerful.

View on HN

95% of the time when a unit test fails for me, it is the test that need fixing instead of my code. It hardly inspires confidence.

That's also my experience, but consider how many of the remaining 5% would have led to a regression that would have gotten shipped in production if the test didn't caught it ? In my experience, this number way above zero.

Is that because you're not writing tests while you're adding code and just breaking old tests?

To me this suggests that there is no clear understanding what your units are supposed to do.

My second theory would be that the unit tests are written by the inexperienced developers while the good developers write the other code.

The tests will involve 5 mocked dependencies just to test a simple if statement. They test the implemention and are a waste of time.

Isolated units that are well tested usually don't need to be updated in my experience so they rarely break.

Tests that have 5 mocked dependencies is usually a signed we done messed up somewhere.

Having a robust test suite is very nice. Having an overly pedantic test suite is not. Things like getters / setters that use the same library you've used 1000 other places have no need to be tested again. Add tests for the base concepts and trust that they'll continue working based on those.

Reply on news.ycombinator.com