Backbone Models in 10 tests
I think understanding Libraries and Frameworks is one of the most fundatmental things a Software Engineer can do. Understanding the underlying system allows you to get the most out of it. It helps you design new features and debug knarly bugs.
Understanding the system that’s one or two layers below your software also helps you understand that abstraction that it’s built on top of. This layer is more generic by necesssity and will help you understand the shape of your objects and the constraints they will adhere to.
So, how do you go about building this understanding. A good place to start is tutorials and books. These resources will give a good overview and theoretical grounding, but you won’t get your hands dirty. You could download the code and read it. This is often frustrating because the libraries are mature and even the core classes have several edge-cases and feature bloat that will make it hard to understand. The best way to find the core bit of logic is to use git to go back in time to when the library was just built. The developer was probably thinking about building the “simplest” thing and that’ll be the code you want to read and play with.
Reading code will probably only get you so far. Reading is mostly a passive activity and learning is best when it’s active exploration. There are three good ways to play with a Library: fix a bug, remove a key component and try and add it, build tests or code that exercises it. All of these activities are better by going back in time with git. A bug in the early days is more fundamental and interesting. A commit could cover an entirely new feature, so if you’re reading the commit logs and find a featrue that you want to add, checkout the commit before and try and implement it yourself.
The other day, I was designing an interview for a front-end dev and wanted it to be hands-on conversation provoking so I built most of Backbone’s Model and Event classes as it looked a month after the first commit in 10 unit tests. I called the project Barebones!
Here are the 10 unit tests:
- Model set
- Model get
- Model initialize
- Model defaults
- Model bind
- Model trigger
- Model trigger with scope
- Model trigger with args
- Model set, which triggers a change event
- Model default should not trigger a change event
As an exercise, I’m really happy with how the finished product is a usable data object. I also really like how the tests build on each other. Set and Get are trivial primitives, but layering in defaults and event-hooks makes you re-think strategies for reading and writing the data.
Check out the Barebone Project on github. Also, checkout the commit history to see how each test was added. And if you want to do it yourself, I recommend deleting the barebone.js file and running the specs yourself!