The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How do I unit test code that uses the serial port?

Hi,

I'm building an application and I'd like to use unit tests to cover as much code as I can.  What do I do about code that writes to and reads from the serial port?  How do I verify that it is working properly?  The only thing that I've thought of is plugging a null modem cable into two serial ports and checking the output of one with the input of the other, etc.

Any ideas?
Brendon Send private email
Wednesday, February 08, 2006
 
 
Not too sure which language/libraries you're using, but an approach is to create a mock of a device that is connected to the serial port.

The steps would be:
1) define an interface to the serial port
2) your application code make calls through this interface (not directly to the serial port libraries)
3) create a mock implementation of the serial port interface
4) your test cases use the mock which returns "canned" good or bad results, depending on what you're testing, and how much of your application code you want to cover.

This way you don't need to have the actual serial port device.
James
Wednesday, February 08, 2006
 
 
I assume you are interacting with a 3rd party library, not directly with the hardware?  If so, why not simply create a stub?
dave
Wednesday, February 08, 2006
 
 
I'm using a third party component to handle the serial port and I want to make sure that not only am I sending it the right stuff, but that it also correctly does what it is told.

I want to ensure that it sends the right stuff out of the serial port, and that it passes the right data back when it receives data.

I also want to check that when I specify the size of the input and output buffers, it actually makes them large enough.  The function used to do this does not return success and it only uses the size arguments as recommendations, it will ignore them if they are "invalid", whatever that means.
Brendon Send private email
Wednesday, February 08, 2006
 
 
I would use something like Port Monitor from Sysinternals to determine if the buffers are being created at the right size. Then I would use the loopback method you mentioned using either a physical cable or software loopback driver. The physical cable route is probably going to end up being the most accurate.

I have used Serial Monitor from HHD to do similar monitoring. It is a fairly cheap tool and does a much better job than the free Port Monitor tool from Sysinternals.
anon
Wednesday, February 08, 2006
 
 
In this circumstance I've been known to get a laptop, program it with the prompts and responses, and attach it to the serial port under test.  Usually with a Radio Shack RS-232 monitor box so I can see the state of the handshake signals.

It's the only way to be sure.
AllanL5
Wednesday, February 08, 2006
 
 
But, if you want to use a program on the same PC to read and write a second port on the PC, with a null-modem cable connecting the two, that can also work well.
AllanL5
Wednesday, February 08, 2006
 
 
Create a test "server" on another serial port, and run a null modem between the two.
Mike johnson Send private email
Wednesday, February 08, 2006
 
 
Thanks for the suggestions, it's nice to know how other people handle this.
Brendon Send private email
Thursday, February 09, 2006
 
 
Been there, done that some time ago.
We used ComTest (think it is this one here: http://www.livenote.com/Downloads/serial.html), running on a couple of old junk laptops, or an expensive bit of old hardware (an HP serial protocol analyser).

Both had a huge advantage of being able to capture real data streams coming from SCADA systems or modems/handhelds, enabling us to debug weird problems with things like early Windows CE devices and more importantly, replay the captured data. Thus if we found problems that were fixed in a data stream, we would keep the data as a file for playing back in our regression test suite.

Hard to fully automate all serial testing, but we employeed    students for unplugging & plugging cables and pushing buttons to cycle through regression tests.

(BTW - people still use serial ports? Thought it would all be USB or TCP/IP over the network by now)
Grant Send private email
Thursday, February 09, 2006
 
 
Electrically noisy environments can still require something like a current loop serial network so that the data is guaranteed to get through.
Simon Lucy Send private email
Friday, February 10, 2006
 
 
Serial is still great for some apps - RS485 will go ridiculous distances in harsh envs with very little data loss. Even 232 is more rugged than USB for some stuff.

Don't forget to stick a loopback test in there somewhere - stick a connector with rx joined to tx in the PC and check that what goes out comes back. So if it stops flying for some reason you can do a quick sanity check.
revert my buffer
Friday, February 10, 2006
 
 
> I also want to check that when I specify the size of the input and output buffers, it actually makes them large enough.

How would you hope to do this? The buffers are private implementation detail of the serial.sys device driver. If you wre using a different driver (eg. with an 'intelligent' serial board) it wouldn't be easy for the app. to tell the difference

The size of the device driver's private buffer determines how much data the driver can receive before it flow-controls incoming data through the port, which happens when it's receiving the data and you don't have an outstanding ReadFile (or aren't sending ReadFile buffers down to the serial driver frequently enough). If you *do* have an outstanding ReadFile then the received data is copied into that and the port need not be flow-controlled. Best performance (needed for some protocols which don't tolerate flow control) might be to have two outstanding (overlapped) ReadFile (each with its own buffer):

* ReadFile x 2
* Data received => 1st ReadFile completes
* You read the data from the 1st ReadFile and then resubmit it (i.e. do ReadFile again), while your 2nd ReadFile is still outstanding and able to receive data while you're handling the completion of the 1st ReadFile
Christopher Wells Send private email
Tuesday, February 14, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz