Test Driven OBEX

Way back in June I was playing around with OBEX. I’ve had a quiet day today and went back to the code to progress it a little more (a client is making interested noises so I need to get back up to speed again). The code I wrote in June was before I’d become test infected

The first thing to do, of course, was to add a test harness and a mock object library to the OBEX library. Once that was done I wrote a test for the most appropriate looking object and watched it fail. Since then I’ve been getting back into the swing of OBEX whilst allowing the OBEX test spec to guide me in the tests that I need to write.

It’s interesting to see how different the code that I had written in June is to the kind of code I’d have written more recently. The style’s fine, the code is sound but the areas covered are completely different to the areas that would have been covered if I’d been doing the work test first. I have a parser which parses the incoming byte stream and deals with the OBEX requests. It does this by building an OBEX object, checking the op code, parsing the rest of the data into OBEX headers, passing the object and an empty response object to the appropriate handler, allowing the handler to build the response object and then serialising the response object and sending it back to the client. Which is fine, but the object and header and response are all wrong; well, different. They have a lot of ‘visible debug’ methods, like Dump() which takes an object and gives you a textual story about what it contains. Header has a Dump() too. Dumping an object dumps the headers. It’s a handy way to understand what’s going on but it’s all just fluff when you have tests… I’ll probably keep the code for now, but it’s not the code I’d have written first if I was working from a test. I wouldn’t need it yet… I may never need it in production…

And, of course, the second test I wrote today broke one of the underlying assumptions of the original code which led to a redesign…