3 ms·
Unit tests aren't really about testing (in the validating sense) software. They in fact are quite deficient in that role. No integration tests, no end-to-end t
by njharman 10y ago
Unit tests aren't really about testing (in the validating sense) software. They in fact are quite deficient in that role. No integration tests, no end-to-end tests, no fuzz testing, etc.
Unit Tests are foremost a software development tool. They force (in order to be unit testable) separation of concerns, definition of interfaces (i.e. the "contract" with function's users), etc. Mechanically, they also enable validating that internal refactoring has not violated that contract.
- gwbas1c 10y agoAs big of a fan as I am about unit tests, I find their value somewhat dubious. They take a long time to write, and when they fail, it often means the unit test needs to be updated. Mocking interactions among objects takes a long time. What I find has a better ROI is using the same unit testing tools, but writing what unit test purists will call integration tests. Basically, using unit test tools where most of a program is instantiated, but I/O is mocked, is much more useful. When these tests fail, it usually indicates a bug instead of a part of a unit test that needs to be updated.
- flukus 10y agoIt sounds like a problem with your tests actually. Unit test shouldn't take a long time to write and the should only fail for a very specific.
- njharman 10y agoThis is why/how they are a development tool. "Mocking interactions among objects", often breaking, taking too long to write (I expect to spend 30% dev on units, 30% on code rest thinking, planning, etc). Those are all indicators that your code/architecture is bad. Too complex, too coupled, too much concern, not layered into clean interfaces, etc.