opinions on automated unit testing

In my previous job, we developed a new GPS receiver architecture and algorithms to take advantage of it. We wrote a simulation of the hardware in C, and had sampled data files from a GPS RF front end. These were used to develop the control software and advance the receiver architecture design.

It was extremely slow, but worked well. The target was not a PC, so we had a number of conditionals to hide the compiler differences and cover some of the shortcomings of the hardware simulation. All told it was pretty successful.

In the past, I have developed algorithms on the PC that I later ported to an embedded platform. It's pretty effective, especially if the target hardware is non-existent, hard to access or flakey.

Bob

Reply to
MetalHead
Loading thread data ...

That would be done with a code coverage analysis. (i.e. instrument the code under test, then run the test, see if that leaves any white spots in the code under test, i.e. code/conditions that have not been exercised by the test.)

There are some nice tools available for doing this, but given their typical price tag, i guess not many people actually use them, unless they are forced to (e.g. by DO-178B).

Rob

--
Robert Kaiser                     email: rkaiser AT sysgo DOT com
SYSGO AG                          http://www.elinos.com
Klein-Winternheim / Germany       http://www.sysgo.com
Reply to
Robert Kaiser

No argument there. You are correct, it is mandatory in some industries. We do testing for safety-critical embedded software so I see those industries all the time. Even then customers send us software they think is ready to go into very critical systems that scares me half to death.

In the others I stand by my estimates.

Scott

Reply to
Not Really Me

The College of Engineering has grown that much in the years since I was there?!?

There are (semi-)automated testing tools available and used for areas such as mathematical processing. There is no excuse for some sort of testing of math libraries, for instance, but there aren't very many people developing those.

A good illustration of the value of testing that I saw many years ago is the exercising of all execution paths in code. It was amazing the number of bugs uncovered by even that crude testing...

Reply to
Everett M. Greene

Testing with 100% code path coverage is always worthwhile and is easily accomplished in incremental development regimes (where you build the system bottom up and prove the lower layer is good before using it). Combine the incremental approach, unit testing and a decent Configuration Management System and you begin to get the ability to be fully confident in applying certification to your software.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/********************************************************************
Reply to
Paul E. Bennett

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.