Do you use TDD to help shape your application’s design? I do, although I’m not as strict as I used to be. I used to test eeeverything, now, not so much. I was a fly on the wall during some Agile coaching sessions from “The Dude” at my shop; he kept making a statement during one particular coaching session – “Let’s not try to boil the ocean, ok?”
I know he’s not the first one to say this, it’s a pretty common saying. The context was around stories, epics, and setting up a story map and making discrete stories that can simply organize work items for the team to work on – small bites, Legos – pick your analogy. It just allowed for the story map to flow better and to give the team context around what’s next, and what “it” is what’s being accomplished.
I try to do the same thing with TDD – as I’ve mentioned in other blogs, testing the framework isn’t as valuable as testing your own code, right? I mean, if there’s a bug in a(the) framework you’re using you’re going to find it sooner or later if you are pressing any particular namespace pretty hard.
One thing I also learned from Uncle Bob was that TDD can help you understand a framework – probably not as much as Code Kata, but so TDD helps me understand the namespace(s) I’m working in and keeps the context and responsibilities of the classes tighter and more cohesive.
Moving on…
I started out trying to boil the ocean for the Windows Azure Media Services (WAMS) because I didn’t get how everything was wrapped together and how things were processed. There’s things you can’t mock, but some things you can. There are many interface types you can implement to make your own mocking types for quicker tests, and understanding these interfaces once they’re implemented inside your own concrete types helps tell the story of what they’re doing. Here are a few that I worked with extensively while I was baking my infrastructure classes: IAsset, IJob, and ITask – I got a lot of mileage (and headaches) unraveling and re-wrapping this stuff for my little brain.
Reducing the temperature from 212F (100C) to a light simmer…
I started with the business layer tests, the thought being I’d spin up some fast(er) running tests in that space first, then move into the infrastructure layer(s). The effect was my business layer tests had too much code in them. I was building up some of the infrastructure types while I was building the business layer types and tests – not good. So I stopped and just focused on the infrastructure bits. Here’s how the infrastructure assemblies looks right now:
There’s four separate services I’ve created for interacting with WAMS. Each service is something you can do with the WAMS portal, and I wanted to break it up like that, the only thing missing is a publishing service that actually tosses the media over the wall and a URL is assigned to the content you’ve uploaded and encoded.
I’m not using an IoC container yet to spin up concrete types for me, so to keep the tests simple for now I’m just building the concrete types by hand.
This was all I need to do to keep the infrastructure types from polluting my business unit tests. Most of these infrastructure tests are bouncing up against WAMS for now, but my business layer test will be using a few mocked out types using the interfaces I mentioned above. Once the publishing service and the business layer tests are built out I’ll blog those, but now I’ve got to put some thought into how this application is going to use the business layer, so it’s time for a little (more) story mapping.
HTH
oFc
john@scale 
You must be logged in to post a comment.