Growing Object-Oriented Software, Guided By Tests (chapter 19)
Feb 22, 22At this point of the book, we turn our attention to error handling - unfortunately, a required evil!
First of all, annotate your state machine with the potential error states. We can’t cover them all, but it will give you a good idea of where the ‘seams’ of your system are.
Start with an end to end test as usual.
Use a generic try/catch if you need to catch a non-specific error.
Remember the single responsibility principle while designing error handling - do we need additional objects to handle when things go wrong?
Think about which collaborating objects you will need - should they be dependencies, or notifications?
Don’t be afraid to break the rules a little while testing - if you do, just make sure that you have a good justification for it, otherwise things could get very complex!
We should try to develop software incrementally, in small manageable slices. Once we get more accustomed to TDD, these chunks of working should flow nicely, and help to guide us to a well designed, and robust system.
We should have something working, and just be adding features at a time. Think of the 3 point rule from rock climbing. Keep 3 points of contact with the wall, while 1 body part moves to propel you upwards.
The only constant in software development is change <- make sure you are prepared! We should have a loosely coupled system, that is easy to change. Test behaviours, rather than methods to stop tests getting stuck to the code.
Try to write small methods to express intent, and give meaningful names to them!
Logging is a feature, and should be as loosely coupled as the code - Organise your logging as such (with clean interfaces).