Some (raw) thoughts on what are the elements that give you a quality and testable code.
It’s not a full list of TODOs but some best practices that should serve you as a good baseline. If you have any suggestions, please feel free to comment.
If we agree that you must have tests in your project – The next good question is what is a good test?
- It’s FAST – The tests should run fast in order to encourage developers to use them constantly during the development process.
- Stable – The test doesn’t break often. You wish to minimize the false-positive ratio as much as you can. This is why you need ‘small’ tests that are encapsulated and give you a clear sign on what is working (or not).
- Easy to read and understand.
- Catches Bugs! When a test fails it’s most probably a bug.
Code reviews are a critical part of you pull request process.
- Here is a good tutorial to Code Reviews with some useful recommendations.
- Understanding code review from Google testing experts.
- You can use a SAAS option like Sonarsource
- SpotBugs – Can be part of your build/dev process.
- There are many other options to use linting extensions/plug-in so you will catch many issues during development time.
- Have a good (~75%) coverage of your code with unit tests. It should be a good coverage to effort ratio.
- Make sure you have unit tests, integration tests, functional tests, end-to-end tests and it’s all automated and part of your build process.
You wish to have around 70% unit tests (which are ‘small’ tests that run fast and encapsulated), 20% for integration tests and 10% for UI (or end-to-end) tests.
- When you have an issue with production → You creating a test to cover it in the future.
- Learn from your (and others!) history.
- Build a process of debriefing after each time something happened (or almost happened) and create a test that covers this case for the future.
- You can test in production but think carefully if it’s the right thing to do for your specific case.
Can you use Mocks, Stubs?
Anything else you wish to add?