The most striking part about MPJ’s series on unit testing is his biting and hilarious incarnating and characterization of the three most familiar voices in many developer’s minds: the anxious, the judge, and the over-engineer. Just watch one of the videos. Those names are my own, by the way. (Challenge: figure out which voice is which name I’ve given it!). Developing this further, I like to call them the Office of Sabotage. I actually thought of Amanda Palmer’s “fraud police” as I watched MPJ’s video for the first time.
I really could engage with the anxious voice today as I hunkered down to write some tests for a feature I’m pretty much done with. Yeah, I know, real TDD would have entailed to do it first! Baby steps, bro…
This became easier. I could see the code I was testing and it made it easier to work backwards.
Context: I’m writing tests for a feature that sends text messages using our internal system. There are three components:
- the front end controller
- the front end factory that calls the API controller
- and, the API controller that consumes the back-end endpoint
As I ignored the Office of Sabotage’s attempts to… erm… sabotage me, a couple things occurred to me:
- We just assume that the API controller will always receive the POST parameters, there are no checks at all. Something I should cater for in a test…
- The error handling is a little clunky and not harmonized. It almost feels too brittle. Something to be dealt with in a test and maybe reworked in the refactor!
Today was just day 1. Tomorrow was a new day. When I got stuck, I fired up the video and just coded along.
Will report back (and write more about TDD)!