This lesson is divided into 5 sections:
- Short warm-up discussion (~20 minutes)
- Student exercise
- Share out
- Review potential refactor
- What does ‘single responsibility’ mean in a programming context?
- How does programming with an eye towards the single responsibility principle help us as programmers?
- In past projects, what have you decided to test? What have you decided not to test?
Data Pains - limiting our interface to our objects
- Common pain point when dealing with external interfaces: we make the external data dump the only interface for sending information into the object
- The action of bringing outside data in is contained within the object, so our only way to provide it is to put the data in the right place (often a file) and let the object slurp it in
- Programming with files/HTTP sources/Network data drives us to program with Locations rather than values
- Rather than telling you the value of something I’ll tell you it’s on the whiteboard in the other classroom. Then you have to go look it up.
- What does this mean for our tests?
- What would an alternative look like?
- Can we preserve the simple data interface (i.e. provide data in the form of ruby objects) as well as the “slurp it up from a file” interface?
- Best of both worlds: Testability and flexibility when you want to provide standard basic objects; Ease of use / “Do it all” when you need to pull in a bunch of external data
- Additional win: If the importing task becomes more complex, we can easily extract it into a separate entity
- The interface between our objects is simple data, rather than external infrastructure
Exercise - TDD Pizza Parlor
Keep these principles in mind as you complete this short Pizza Parlor Exercise
- What did you test?
- What didn’t you test?
- Can you test more if you refactored your code?
Review Potential Refactors
- Can we isolate the file I/O?
- Can we extract it to a class?