Decomposing Composers: a #30DaysOfTesting Testability Entry

Wow, it's almost the weekend and then next week will be STP-Con. More to the point, by the close of Sunday, I will be out of days in March. Ugh, why did I wait so long to get to these?

Frequent readers, please don't chime in. I know that you know exactly why ;).

Anyway, best get a move on, these things aren't going to write themselves, after all. More "30 Days of Testability".

Decomposability is an important part of testability. Complete our circuit breakers testing exercise over on The Club!

For the full description of this, head over to the Circuit Breakers exercise over on the Ministry of Testing's site. In it, there is a recommendation to read two additional resources:

• Martin Fowler: Circuit Breakers
• James Espie: Testing In Production The Mad Science Way: Circuit Breakers & Science Experiments

The general idea behind a circuit breaker is that new code can be introduced and tested without removing older code. Think of it as a parallel circuit with a trigger. We want to use the new code, but what if something goes wrong? Do we just want to accept the failure or do we want to be able to revert to the older code in that instance? If we want to use the older code, then that's where the circuit breaker comes into play. If it's thrown, the older code is run instead of the newer code.

The idea behind the science experiment is that there is an A/B test performed. The new code is run, old code is run and the results are compared. If all goes well, the old code will be marked for deletion or review for being removed. If there are any issues, then the new code will be flagged and the programmers can review it.

Choose an area of an application of your choice to decompose. Identify where you might add circuit breakers to this system. Share your reasoning on the Club.

We have been in the midst of a Responsive UI redesign for the past few months. To that end, there is a lot of new feature code that allows for how certain elements are going to be displayed. In the event that the code in question isn't present, those elements (we call them widgets on our product parlance) will likely not display correctly. For this purpose, it would be helpful; to have a way to see if a widget being applied will appear correctly in legacy vs. responsive UI. Sure, we could load each widget and see, but wouldn't it make more sense to create a circuit breaker that would alert a user that the widget in question doesn't have the code block necessary for it to appear in responsive UI and thus alert the user (or the test) that that particular widget won't be usable yet?

So why would this be helpful? Basically, it comes down to what we want to spend time on in a given sprint but not have to retool everything so that tests that pass with one widget will fail with another simply because the code for responsive UI hasn't been implemented yet. Since we have dozens of widgets, making a change so that either an A/B comparison can be made ("hey, I see that this widget you are looking to load doesn't have the block of code that indicates it will work in Responsive UI, let's flag that. It's not a failure but it's something we want to have an indicator that work is still required for.") or we put in a circuit breaker ("Whoa! This widget doesn't have the code for responsive, so load the legacy widget.").

Both are interesting approaches. I shall play with these some more going forward :).