I write Linux embedded software which closely integrates with hardware.

My modules are such as :

-CMOS video input with kernel driver (v4l2)
-Hardware h264/mpeg4 encoders (texas instuments)
-Audio Capture/Playback (alsa)
-Network IO

I'd like to have automated testing for those functionalities, such as integration testing. I am not sure how I can automate this process since most of the top level functionalities I face are IO bound. Sure, it is easy to test functions individually, but whole process checking means depending on tons of external dependencies only available at runtime.

  • 4
    usually you use dependency injection to pull in an alternate (non-io) input stream to process
    – tylerl
    Commented Jun 3, 2012 at 6:29
  • I want to test if my hardware behaves correctly without building a full emulator for it. I cannot creates a stub complex enough to simulate every behavior for my hardware. How can I know if option #38 = 4 and option #45 = 1 doesn't break everything?
    – Eric
    Commented Jun 3, 2012 at 6:38
  • Well, hopefully the encoders don't depend on the io implicitly? Then use test cases to only test your encoder. If your encoder has options 38 and 45, set those to different values in different cases. If those are io options, test them only with the io :)
    – Max
    Commented Jun 3, 2012 at 7:41
  • Oh, sorry. Didn't see that the encoders are hardware. Still, I guess you have a api that let's you output the video to somewhere else than the screen? If so, use that to output to a stream or file and test whatever parameters you like.
    – Max
    Commented Jun 3, 2012 at 7:44

1 Answer 1


Sounds like a job for loop back testing. Strictly speaking, loop back testing might feel as much like integration testing as it does like unit testing, even if the primary goal is to test just one particular device's support of configuration, input, and output.

For the audio device, perhaps you can do the following:

  • Wire a physical loop back of output to input.
  • Configure gains, sample rates, etc. as needed to insure functional and code coverage.
  • Playback a data file A and capture it back as B.
  • Compare A and B in some suitable way to determine pass/fail.
  • Repeat with multiple data sets to cover valid and invalid test cases.

Similar approaches are possible with video and network loop backs.

A few additional suggestions:

  • Use of lossy compression or noise may limit your ability to compare capture files.
  • Use of simplified inputs like tones from frequency generators or and video from generated color bars might work better than a track from your favorite rock band and a clip from an action movie.
  • You may want to play with the gain or run the samples through an FFT and compare the outputs of the FFT.
  • If comparing content gets too hard, checking duration, or verifying by ear or eye might be a way to get 'er done without making test code that is more complicated that the production code.

Good luck. Hope this answer helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.