In my company we develop medical data-acquisition systems. The main functions of each application are:

  1. Interface with data-sampling hardware;
  2. Save/load collected data to/from files on disk;
  3. Perform mathematical analyses (DSP, image processing) to collected data;
  4. Display/plot the information using a graphics-heavy UI;

As far as I know, these are exactely the application areas that most textbooks on unit testing recommend "not to test", or at least that should be left as thin as possible (GUI typically) so that you can test the "true" functionality that has been put elsewhere (say, at the model layers).

I am genuinely commited to raise the quality standards of our software projects, but the nature of our applications, and these counter-indications found on texts about the subject, make me think if that is even possible, and if so, how could I circumvent these limitations.


You mock out the things that you don't want test, and write tests that purely exercise the business logic.

For instance, you don't want to test the file-system read/write code. That is the file system implementer's job. You do want to test that your code transforms data the correct way. Therefore, decouple the data loading from data processing, inject a loader that imports carefully crafted test data, and verify that they are transformed in the expected way. What you're describing is precisely the reason that people recommend the dependency inversion principle so much.

| improve this answer | |

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