Loading ...
Sorry, an error occurred while loading the content.

120200Re: [XP] Is there anyone who uses xp methods in embedded applications?

Expand Messages
  • Russel Hill
    Jun 1, 2006
    • 0 Attachment
      On 6/1/06, Micron Engineering <micronpn@...> wrote:
      > C projects
      > I divide the sw in modules where module = file and every module has its
      > test functions and its main() (for embedded applications the startup
      > function is common to every module). This means that I write one or more
      > test functions for every function contained in the file. Now, to manage
      > better the test functions I decide to use this approach:

      I like to split my tests into a separate compilation unit. This has a
      couple of distinct advantages:

      1) I have the liberty of writing C++ test against C code (I like this one)
      2) I can compile application code _once_ and then use the linker to
      control whether the test harness or main is in control.
      3) I like it better that way.

      > I read about stub functions to substitute functions called inside a
      > function to test. Actually I am not using them also if I understand that
      > may be better isolate any single test but I really don't understand the
      > way to do that.

      Stub functions are particularly troublesome in 'C' (and some C++). It
      is possible to stub functions (or entire libraries) at link time. This
      is not a trick that I keep close to the top of my bag but it is
      occassionally useful. This would be another reason to keep test/stub
      code in separate compilation units.

      > to test IntSum() I need to test the returned value to see if it is
      > correct. To test Series() I may understand what to test but I don't
      > understand what may be the stub function and if it is a very advantage
      > to write the stub function.

      In your example, there isn't much reason for a stub. Consider:

      void toggleResetBit()
      {
      *controlRegister |= resetBit;
      *controlRegister &= ~resetBit;
      }

      void reconfigure()
      {
      toggleResetBit()
      // do a bunch of other stuff
      }

      If you want to test that reconfigure actually calls toggleResetBit(),
      then you could link in a different implementation of toggleResetBit(),
      such as:

      void toggleResetBit()
      {
      someoneCalledToggleResetBit = TRUE;
      }

      and then:

      void testReconfigure()
      {
      reconfigure();
      Assert(someoneCalledToggleResetBit);
      }

      Whether this is an important test to write, or not, is between you,
      your team, and your customer(s).

      Testing that toggleResetBit does what you expect is an entirely
      different problem. Is left as an exercise for the interested reader.
    • Show all 14 messages in this topic