I'd advise two levels of tests: Start with actually testing the service
When that gets too slow and becomes painful, then build mocks, stubs, or fakes. Run the 'real' 'big' (slow) tests occasionally in the background, and do your TDD with the mocks, stubs and fakes. Try to have a balanced breakfast. Finally, I'd suggest writing a tool that allows you to "manually" "poke" the service to check the results - say a command-line tool that just takes some inputs and gives you what the service outputs. That way when you get a test idea, you can explore it cheaply for several combinations, and code up the explorations you found most valuable and are most likely to want to repeat. I covered some of this a couple of years ago in a Google tech talk: http://www.youtube.com/watch?v=PHtEkkKXSiY (Oh, seriously finally - there are no standards in software testing; instead, the value of any practice depends on it's context: http://www.context-driven-testing.com/ ) all my best, --heusser On Tue, Sep 28, 2010 at 7:25 AM, Spiros Denaxas <s.dena...@gmail.com> wrote: > Hello, > > I am venturing off to write a module which will act as a wrapper > around an online API provided by a third party. I am trying to plan > ahead of time how the tests for it will work. > > On the one hand, I am thinking that creating a test with the module > that accesses the actual online service might be the most accurate way > of testing things, on the other hand I am not sure if this is the > "canonical" way of doing things. I have done some reading around and > some people suggested that instead of hitting the actual online source > one should mock the output it returns tand take it from there. In the > past, I have actually written tests to hit the live server but I am > wondering if there's another way to this. > > Is there any standard way for this sort of thing? > > thank you for your help, > Spiros > > -- Matthew Heusser, Personal Blog: http://xndev.blogspot.com/ Test Community Blog: http://softwaretestpro.com/blog/ Twitter: mheusser
