- Code reviews
- Static analysis
- Health monitoring: availability, resilience, etc’.
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 without tests is bad code. Even if it’s looking clean and efficient. Without tests you can’t change it in a verifiable way.
You can’t know if your code is getting better or not.
It’s not a new idea.
But it’s amazing how many times developers will ‘cut’ corners or won’t implement tests because they are too busy to ship a new feature.
In many cases, it’s the opposite case, if you wish to move faster and safer – you need a good tests suite that give you the confidence that your changes didn’t break anything. You wish to have unit tests (wide coverage of functionality and running fast in an automated way), integration tests (a bit slower but still fast and in many cases, with mock data) and end to end tests (Yes, in many cases, in a real production environment). Continue reading