Intro (5 minutes)
As you learned to build more complex applications, we gave you Rails. As a framework, one of Rails’ jobs is to help you organize your code. Logic that is related to a resource belongs in that resource’s model. Logic related to a view belongs in a helper.
This doesn’t just help you organize your files – it helps you organize divide responsibilities in your code. You don’t really have to think about what’s unit testable. If it’s in a model, it’s unit testable.
By the end of this workshop, you should be able to:
- Add unit tests to your front-end application
- Understand how to approach refactoring client-side code for unit testing
- Understand and be able to speak to why unit testing client-side code is complicated
How Should We Think About Unit Testing? (20 minutes)
After 15 minutes, turn to the person next to you and compare/discuss interesting parts of the reading.
Murpy’s Four Areas of Responsibility
- Presentation and interaction
- Data management and persistence
- Overall application state
- Setup and glue code to make the pieces work together
Activity (25 minutes)
Using the four areas of responsibility from Murphy’s article, go through this partial Quantified Self implementation and take a first pass at highlighting the pieces you think belong to those certain sections.
After about 10 minutes, turn to the person next to you and compare/discuss your results.
Application (25 minutes)
Get together with your project partner. Find a function within your codebase that would be a good candidate for refactoring based on what we’ve just learned.
- Make a copy of the function you’re about to refactor, so you can compare when you’re done.
- Pick apart the different logical steps that are taken in this function
- Determine one or more functions that could be extracted out from your main function
- Try to write unit tests for those functions before refactoring them
- TDD your refactor
Spend about 10 minutes doing this for one function. We’ll close by seeing some of your solutions.