The JasmineTester is going to be updated to accept a random number of values. The first step is to create a unit test to describe this. The number of properties being added is upped to 4. The new test will check to make sure the new object constructor still returns an object by using the toBeDefined matcher.
One reason to unit test is to confirm your code works despite internal changes to the source. As your application changes and matures, it can be daunting to ensure your old code still works. Properly created and maintained unit tests make this much less scary. You add a feature, run all your tests. Everything passes, then you are in good shape. If something breaks, you know it now and not when the customer finds it. Once everything passes you can move on to your next set of changes with relative certainty your application still works. This post will set us up to show that principle in action over the next 2 posts.
Unit testing and I have had a tumultuous affair until now. Every few months I would pick up a book, go on a blog reading binge, or try out a framework. It would never work out. I would get frustrated or work would intervene and off I went. Unit testing and I were almost fated to always be apart... <cue the romantic music>
An opportunity came at work to create a new feature on our web platform. I decided to take a chance and build it from unit tests. It was a great opportunity to start clean with very few dependencies to worry about. The lack of entanglements made it easier for me to understand how unit testing would work to describe this new piece.
Our first example was a simple event bubble from a button to a parent object. The second example re-used the button object within two separate parents that handled the bubbled event differently. Let's go one step farther. This time the button's event will bubble all the way up the parent hierarchy.
We looked at a simple example in Part 1. A button component sent an event up the object hierarchy until it was captured by the App kind and resolved. Wouldn't it be great if we could use the same BubbleButton kind in 2 different hierarchies and get 2 different results? Yes it would; so let's do that.
The bubble method allows events to be sent up the object hierarchy. This is not the same thing as bubbling up the DOM. The object structure that is in memory can be similar to the DOM, but the process will only work against the object hierarchy. Changes to the DOM will need to be rendered separately.