Magic Tricks of Testing @ YouTube
It’s a nice talk about testing.
The costs for testing takes major part of the development, and also there’s no way to verify the 100% complete. Therefore, identifying the method that maximize the cost-performance is crucial. This session talks about the practical way to limit the scope of unit-testing, based on the message types (query and command), their directions (outgoing and incoming).
Good part of the unit-tests is that they perform the important role on quickly identifying the mistakes in the code. However, there is also a bad part that the maintenance costs (especially for the flaky ones) can prevent the fast development. This kind of scoping is a good one to apply.
Also, I found the following viewpoints interesting.
- Deleting extra tests (which easily brakes) can be an option.
- Temporarily adding extra tests (for private methods, etc.) can be an option.
Too much focus on enforcing basic rules could reduce the productivity, and it may be good to have this kind of exception under some conditions and rules.
There are many scenarios that simple rules cannot cover the real situations, like existing code-base that doesn’t have tests, or some difficult codes to test. Technically speaking, most of the cases may have solution, but sometimes it’s not practical, due to various reasons (lack of time, lack of skills, etc). Putting a decent fallback plan over the fundamental rules would be an important factor.
- Test incoming query message by asserting the query result.
- Test the interface not the implementation.
- Test command message by making assertions about direct public side effects.
- Don’t test private method, as it’s redundant and easier to break. However, temporally breaking this rule can save your time.
- For outgoing command message, confirm the message is sent using “expect” of mocks.