Mmmmmm, coding…….
It’s not often that I get to do much coding these days. Normally I wander around the office offering advice and guidance to others: aka, generally interfering (aaka, managing by walking around). But today was a pleasant change, being a Saturday. I remained cooped up and happy hacking away at a Circuit Breaker implementation inspired by Michael Nygard’s book Release It! That book has enabled me to look deeper into the lives of Ops guys: the poor suckers who have to run the software that developers write, for years on end! Release It! is a truly fabulous book and I recommend every single professional software developer to give it a good hard read (perhaps you could use the SQR3 technique).
Anywho, I got to code and I really enjoyed it. I had written some of this code a while back, but without any tests. I was allowed to do this because it was just a spike – it wasn’t intended to be production code. But today I was to turn it into proper code. Here’s what happened:
- Removed extraneuous code I had added as an experiment into component transparency – exposing this as an JMX MBean.
- Removed other code that wasn’t going to be used in the first cut of this component.
- Create a JUnit 4 test case.
- Unit test #1: test that the delegate call works as expected – just what should happen when the circuit breaker is in the Closed state.
- Unit test #2: test that the circuit breaker trips when a single failure occurs (with the failure threshold set to 1).
- Refactor the test to make them more concise.
- Unit test #3 and #4.
- Refactor the tests, refactor, refactor.
- #5, refactor, #6, refactor, #7….. continue testing various aspects of the circuit breaker.
- Refactor the test cases and again and again.
I had previously written the code as a spike and tested informally using a browser within the webapp. But now I wrote the unit tests to prove that I hadn’t coded any amusing bugs. I wrote each of them so they would fail first, but I was testing existing code – not quite following the word of TDD but living the spirit.
But the thing I brought away from this was the amount of refactoring of the test case I did – I barely changed the existing code which was pair programmed originally. The amount of test code refactoring reminded me of some work I had done previously about how a specific featureworked. During my investigation I wrote a set of unit (missing) tests that got refactored and refactored and refactored until it made sense to someone who might care: not just a developer. This took a good chunk of time to develop, but in the end I was able to publish a literal test as a Javadoc example that would make sense to your Grand Mother!
I did a similar job on the circuit breaker testing – pushing down on the test until it was concise and expressed my intent. I squished and squashed until I had some really neat assert* statements that made sense for this component:
- assertDelegateExceptionThrown
- assertCircuitBreakerFailsFast
- assertDelegateCallSucceeds
I had previously spent a chunk of time thinking about how this component should function and I reveled in the time I was forced to take in making the tests expressive.
I hope to add the ability to monitor the circuit breaker through JMX tomorrow. This time it’s going to be TTD.
Mmmmmmm, coding…….
Related posts: