TDD when some components talk to hardware?

lwicks has asked for the wisdom of the Perl Monks concerning the following question:

I have been hacking away on some scripts to interrogate some hardware via Net::Telnet and issue commands depending on the results that come back. I have been including test:more testing, but am wondering how people would recommend how I might code the subroutines and or tests so that I can avoid actually talking to the hardware. I am curious as to how the more experienced players get around using testing when the items being tested may not be allowed as the hardware (in my case) may be in use. This is also a ongoing thought about how do you test real things without causing problems. Thoughts?

Kia Kaha, Kia Toa, Kia Manawanui!
Be Strong, Be Brave, Be perservering!

Comment on TDD when some components talk to hardware?

Replies are listed 'Best First'.
Re: TDD when some components talk to hardware? by tirwhan (Abbot) on Mar 05, 2008 at 15:22 UTC
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.	[reply] [d/l]
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]
Re: TDD when some components talk to hardware? by moritz (Cardinal) on Mar 05, 2008 at 15:09 UTC
If you use telnet anyway you can write a test server that behaves like the hardware. Depending on the emulated hardware it might be enough to dump the TCP streams with wireshark and emit them verbatimly in your test server. If that's not enough, you have to model the hardware, which is probably not a nice job. In either case it helps to have good abstraction layer, so that you can provide a different backend to test applications that normally talk to your software.	[reply]
Re^2: TDD when some components talk to hardware? by lwicks (Friar) on Apr 18, 2008 at 14:19 UTC
I think I will be going down the route suggested by moritz. In that I think I will code up dummy applications that respond in the appropriate manner. This is becoming approach #1 as I think that my test hardware is going to be moved to a different physical location. Thx. Kia Kaha, Kia Toa, Kia Manawanui! Be Strong, Be Brave, Be perservering!	[reply]


good chemistry is complicated, and a little bit messy -LW
	PerlMonks