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...


Hi Len,
This is regarding the Obex Parser that you have developed . I am also working on the same. Can you plesase tell me how to parse the fields , it will be great if you could send over the code.

After i ran your bluetooth demo server. It gave me two messages :
onThreadCreated - twice
it might have advertised the services. But when i tried to send a file from my nokia 6600 phone, it gave me a sending failed message.

Please i am stuck on this. Can u please revert back on the above issue.



Read the spec, it tells you how to parse the messages. I cant give you the code. We might be able to sell you a license to it. Email me directly if you're interested.

The fact that the server ran up and started its threads means that you have compatible hardware and it will have advertised the services. I cant remember if the server logs its progress to the console or just to the log file (I dont have a machine with bluetooth hardware to hand to test it on), look for a JetByteTools.log file...

Leave a comment