I have written a hell of a lot on unit testing, and given a lot of thought to this over the years - not necessarily on dev.to . I think I put some stuff on Quora too. I don't include any code samples in here, just thinking through unit testing and integration testing. Am referring to c# .Net/.Net Core in this article.
I would advise the very old, but fantastic book - the art of unit testing.
Here is one article I wrote on thinking about data external to tests rather than stubbing way back to tease out integration testing and opening up unit tests to testers.
I see unit tests as being there only as a living document on how the code works or is arranged. I barely write them despite having been through the process a lot.
Most unit test benefit is gained when evaluating calculations and operations - small functions/units etc. The idea of isolating external resources/dependencies seems overbaked too.
NBI was a great .Net Data Testing framework. Seems like Cedric took his site down. Shame. It was a much better approach to use integration testing than unit test stubs for data logic testing.
- Enterprises - low unit tests/high integration tests
- Software Houses - high unit tests / low integration tests
I really have to ask, if in most situations - unit testing is a worthy pursuit? The reason I ask this is for the following reasons;
- The true number of test cases is far higher than can be manually coded.
- Focusing on units does not necessarily focus on workflows.
- Tests can go green without proving the unit works. False sense of security.
- Business logic within unit tests can quickly become stale as domain logic requirements changes.
- Black box testing. Testers hate unit tests as they are buried in code.
- Knowing certain code is covered.
- Seeing a sea of green as the tests pass.
- Integrating error checking/reporting through a CI tool to check whether the tests pass.
- The team can see errors on the Continuous Integration Server and resolve them quickly.
- A measurable indicator.
I wrote this article because it is abundantly clear to me that writing thousands of unit tests just to have a sea of green, that nobody knows how they work is probably a huge waste of time. Heresy we say. Development projects can be more about test coverage than the product.
The right unit tests are great at explaining the code. Furthermore, unit tests can signify breaking changes and this is great.
When developing complex logic, or using Test Driven Development, unit tests can be a good way to give other team members that the code works.
There is a final thing which escapes many people. Stable, well written code/applications which accepts consistent inputs and produces consistent testable outputs may not need any unit tests at all.
- > Written with StackEdit.