in reply to TDD when some components talk to hardware?

When testing modules in isolation, Test::MockObject is your friend. Create an interface which wraps around the actual telnet session, then mock that interface for all things you expect (and don't expect) to happen.

Of course, at some point you are going to have to test against the actual device to make sure that e.g. it doesn't have a bug in its telnet implementation or terminal emulation and that it actually parses the commands the way you expect it to. But those can be run as part of the integration tests and don't need to be run continually while developing (even though its preferrable).


All dogma is stupid.

Replies are listed 'Best First'.
Re^2: TDD when some components talk to hardware?
by ack (Deacon) on Mar 06, 2008 at 04:34 UTC

    I have a loosely similar problem in the testing that we do. In our case, as our larger hardware systems are being 'built up', we frequently don't yet have all the hardware components when we're developing our testing scripts. So it is always a major pain to construct the 'stubs' for the missing hardware.

    So I've been looking around for any 'already-thought-out' strategy to take out some of the drudgery of creating the 'stubs.' Creating them always seems to involve a bunch of standard stuff and then tailoring for the specific behaviors of the specific hardware.

    I have looked around on CPAN but somehow missed Test::MockObject. It sounds (at least on the surface) to be just what I've been looking for.

    Looks like I'll be spending some time getting to know this potential new 'friend.'

    Thanks, tirwhan.

    ack Albuquerque, NM
[reply]

In Section Seekers of Perl Wisdom