Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.arch.embedded
Subject: Re: Unit testing for embedded development
Date: Fri, 18 May 2018 01:23:36 -0700
Organization: A noiseless patient Spider
Lines: 53
Message-ID: <87zi0x9xtj.fsf@nightsong.com>
References: <pdluoq$7rm$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: h2725194.stratoserver.net; posting-host="f0affb4512ce5ff754742fac3a6698cf"; logging-data="30490"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+JGS1gl1mLAEu5qnP+45FD"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
Cancel-Lock: sha1:FekXYZJASfDJjj8/sxg5OjO/648= sha1:C9ctYcw/2r7f8PNIl5AgL9LT3bc=
Xref: csiph.com comp.arch.embedded:27756

pozz <pozzugno@gmail.com> writes:
> Is this the correct way to create a unit testing for a buzzer library?

A good way to do this type of thing with "dependency injection" and
"mock objects".  It's traditionally done with OOP but you can do it with
plain C as well.  You interface the external world through an object so
you'd say (pseudocode):

  class World { ... };
  class Real_world extends World { ... };

  int run(World world) {
     world.buzzer_on();
     world.sleep(1000); // ms
     world.buzzer_off()
  }
  int main() {
     World w = new Real_world();
     run(w);
  }
     
or things like that.  In the real system "world"'s methods would call
stuff from the BSP.

You'd also have a test class, e.g.

   class Test_world extends World { ... };

   int run_test() {
      World w = new Test_world();
      run(w);  // run your application with the test world instead of
               // the real one
   }
      
The test world wouldn't trigger the real hardware, but instead would
just feed the application some canned fake data, and keep a few
variables to track whether the buzzer was on, how much time had passed,
etc.  Then your unit tests would make sure those variables got updated
to the right values.

If you do this thoroughly enough, and have enough logging in your app
code, then when something goes wrong you can translate the logged input
stream into mock inputs in your test world.  Then you can reproduce the
error by running the app with the test world instead of the real one, so
you don't have to go mess with all the buzzers and timers and stuff.
Once you've reproduced it, you can debug it completely in the test world
and with luck, the fixed version will work the real world.

Better yet, you can run and debug the test world completely on your
workstation with its capacious memory and nice debugging tools, without
touching the embedded hardware at all, no cross compiling, etc.

https://en.wikipedia.org/wiki/Mock_object might be sort of helpful.