How to Organise Your Tests?
Fleeting- External reference: https://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/
- External reference: https://martinfowler.com/articles/practical-test-pyramid.html
- see,
If you ever find yourself in a situation where you really really need to test a private method you should take a step back and ask yourself why.
— https://martinfowler.com/articles/practical-test-pyramid.html
big benefit of unit tests: acting as a safety net for code changes
— https://martinfowler.com/articles/practical-test-pyramid.html
getters and setters and all other sorts of trivial code in order to come up with 100% test coverage
— https://martinfowler.com/articles/practical-test-pyramid.html
you don’t test trivial code
— https://martinfowler.com/articles/practical-test-pyramid.html
test as little as possible to reach a given level of confidence
— https://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/
You won’t gain anything from testing simple getters or setters or other trivial implementations
— https://martinfowler.com/articles/practical-test-pyramid.html
A good structure for all your tests (this is not limited to unit tests) is this one:
- Set up the test data
- Call your method under test
- Assert that the expected results are returned
There’s a nice mnemonic to remember this structure: “Arrange, Act, Assert”. Another one that you can use takes inspiration from BDD . It’s the “given”, “when”, “then” triad, where given reflects the setup, when the method call and then the assertion part.
This pattern can be applied to other, more high-level tests as well. In every nbcase they ensure that your tests remain easy and consistent to read. On top of that tests written with this structure in mind tend to be shorter and more expressive.
— https://martinfowler.com/articles/practical-test-pyramid.html