> Similarly, we don’t write unit tests for every new feature. The thing that hinders our ability to unit test is precisely the focus on static structures. Static methods and properties are global, harder to replace at runtime, and therefore, harder to “stub” or “mock.” Those capabilities are very important for proper isolated unit testing. If we cannot mock a database connection, for instance, we cannot write tests that don’t have access to the database. With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love.
Why bother with stubbing, mocking and changing code to be testable if you can use the more useful integration and/or UI tests? They will bring in some great value without having to rearchitect code.
> Why bother with stubbing, mocking and changing code to be testable if you can use the more useful integration
End-to-end tests are useful, but they take a long time to set up, maintain and run. They have to have a live database to connect to and that database itself has to conform to particular preconditions that can easily be violated even if the code itself is just fine. What I've seen, over and over, is that the end-to-end test fail because the test database instance is under load, or somebody wrote a test that inserted some data but forgot to remove it, or it doesn't work right if two particular tests run at the same time, to the point where they report false negatives so often, everybody just starts ignoring them.
Because fine-grained tests allow for more complete coverage of complex but tightly-bounded code sections. For example, if you've implemented a concurrent data structure, it's much easier to verify its correctness with unit tests; with integration tests only, it would be a lot more effort and more difficult, maybe even impossible, to thoroughly test all code paths.
Of course, if your entire software only consists of trivial glue code, then don't bother with unit tests, I guess.
Odds are that the concurrent data structure will naturally be very testable. If it's not, it a matter of abstracting it a bit more, not of using the testability design guidebook.
But well, mocks and stubs is how you test the thing, and has no relation to coding best practices. I think the GP had an unreasonable grouping here.
Why bother with stubbing, mocking and changing code to be testable if you can use the more useful integration and/or UI tests? They will bring in some great value without having to rearchitect code.