Stagger in disbelief if you’d like, but I’ve found an instance where it is more beneficial to not begin testing a piece of software until a measurable way through its development.
You no doubt remember my fabulous, in-development command-line NewsGator client, bulletin. I’ve extracted the NewsGator-specific code to a gem called WonderCroc. The README provides a small glimpse of what’s possible with the library now:
wondercroc
A gem that provides…
In any event, I haven’t written any tests for it yet. A lot of the initial programming was screwing around with Ruby’s RSS parser and running requests through in IRB. At this point, however, I’d like to start throwing specs at it as I refactor it and extend it to become a modular library.
So what?
Well, here’s the thing. I want to know that the library responds correctly to the XML responses sent by NewsGator’s server. I assume the correct way to test this is to mock the responses accurately. The NewsGator REST API documentation provides several partial samples, but they’re not complete or complex enough to give me a full range of parsing opportunities. So why not use actual responses?
So that’s my plan. Extend my WonderCroc::Client class to log the XML responses to a file, and use those in my mocks — something I can’t think of a good way to do if I hadn’t written the code in the first place.
Thoughts?
One Comment
It would be better to get the XML responses through a different library, so that bugs in your code don’t affect them. What if your XML parser adds some garbage data, and then your tests pass because your client works around it (because when you write the it you assume the XML looked like that coming from NewsGator). Then you fix that bug but don’t recapture all the XML you use in your client - now it passes all the tests, but fails on the actual NewsGator site because the XML parser’s no longer mangling things.