0

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.

heltonbiker
  • 1,038
  • 1
  • 9
  • 17
  • 1
    "Perform mathematical analyses (DSP, image processing) to collected data;" - why you don't want to unit test this? – BЈовић Nov 17 '15 at 12:50
  • 4
    Possible duplicate of [best practice when unit testing for embedded development](http://programmers.stackexchange.com/questions/104332/best-practice-when-unit-testing-for-embedded-development) or http://programmers.stackexchange.com/questions/188442/unit-testing-for-a-scientific-computing-library or http://programmers.stackexchange.com/questions/188495/unit-testing-on-visualization-3d-graphics-frameworks – Doc Brown Nov 17 '15 at 13:25
  • @BЈовић I want to test EVERY of the items, including DSP, but I don't know how - that's why I asked the question. – heltonbiker Nov 17 '15 at 14:03
  • 1
    For the record: I have read the duplicates, and I agree: 1) they are duplicates; 2) anyone interested in this question of mine can find the answers there. – heltonbiker Nov 17 '15 at 14:10
  • Thanks @heltonbiker for asking the question, since I am in a similar situation and didn't think of asking or searching here. – toni Nov 17 '15 at 14:25

1 Answers1

3

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.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310