|
|
|
|
|
by rraghur
2475 days ago
|
|
- Don't write unit tests for testing code, use them to guide your design. While that statement is itself is somewhat questionable, it's a little better and IMO reflects the purpose of unit tests better.
Usually, if I'm finding it hard to write or setup a test, that's a signal that something's off.
Also, UTs are absolutely lovely when you're refactoring code - as long as code tests invariants and publicly visible behavior instead of implementation. So even if the part you're refactoring has say 60%, you'd still be in a much more confident of making changes. Code coverage under anything other than unit tests can be very misleading - for ex I've seen places where system & integration tests are run on instrumented code (and little to no unit tests) and since a huge swathe of code will be hit (mostly happy path), there's a false sense of code quality and safety which is probably more dangerous than no tests. Overall, "When a measure becomes a target, it ceases to be a good measure." applies most often to test coverage. |
|