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

creating unit tests in C++

Expand Messages
  • jitesht
    hello, I m somewhat new to refactoring and unit testing. I m trying to use CPPUnit to create a set of unit tests. The problem I m running into is this. My code
    Message 1 of 3 , Oct 1, 2003
    • 0 Attachment
      hello,

      I'm somewhat new to refactoring and unit testing.
      I'm trying to use CPPUnit to create a set of unit tests.
      The problem I'm running into is this.
      My code is in hybrid C and C++,
      and it is pretty tightly coupled.
      for example, a typical method has calls into 2 other libraries, and
      maybe also a db call.

      in order to test a simple method of my class, i end up initializing
      other libraries, the database etc etc.

      i was wondering if any one has suggestions on how to go about writing
      unit tests in such a situation.

      thanks.
      Jitesh
    • Jerome Mueller
      ... Hi Jitesh We tried something similar on a project in C#. Here are some of the problems we ran into: 1. The Unit Tests were too slow (too much coupling with
      Message 2 of 3 , Oct 2, 2003
      • 0 Attachment
        jitesht (Wednesday, 1. October 2003 - 20:09):

        > I'm somewhat new to refactoring and unit testing.
        > I'm trying to use CPPUnit to create a set of unit tests.
        > The problem I'm running into is this.
        > My code is in hybrid C and C++,
        > and it is pretty tightly coupled.
        > for example, a typical method has calls into 2 other libraries, and
        > maybe also a db call.

        > in order to test a simple method of my class, i end up initializing
        > other libraries, the database etc etc.

        Hi Jitesh

        We tried something similar on a project in C#. Here are some of the
        problems we ran into:

        1. The Unit Tests were too slow (too much coupling with 3rd party
        libraries) - I think some of the Unit Tests were more like
        Customer Tests for the 3rd party library.
        2. Strong coupling (even in our code) made MockObjects necessary
        3. Mocking Singletons caused a lot of problems
        4. The tests were run often (with every check in) - but rarely
        discovered anything.
        5. Often more time was spent to get the Unit Tests working than to
        get the change into the code.

        Some of the developers think it was worth doing. I (as the one
        recommending to do it) am not so sure. I've seen how Unit Tests can
        work. The benefit we got from writing them after cannot be remotely
        compared to the benefit you get when you do the tests first.

        It's hard to tell whether the Unit tests had any influence on quality
        (which wasn't very good).

        After seeing those unit tests in action, I think I should have spent
        more energy on other practices (namely Pair Programming,
        Planning Game).

        Jerome

        --

        http://www.jeromemueller.ch

        "Courage is resistance to fear, mastery of fear - not absence of fear." -- Mark Twain
      • Chris Hanson
        Instead of rewriting everything from scratch (a completely unworkable piece of advice in almost all cases), you can start using good practices on all new work
        Message 3 of 3 , Oct 2, 2003
        • 0 Attachment
          Instead of rewriting everything from scratch (a completely unworkable
          piece of advice in almost all cases), you can start using good
          practices on all new work and use that as a way to push them down into
          old work.

          (1) Any time you add a new feature, first create unit tests for the
          code that will be touched by the addition. Refactor the code as
          necessary to make it possible to do this without having to do a ton of
          set-up work to test each method.

          (2) Then add the new feature using test-driven development: Writing
          unit tests for your new feature first; only write code for the feature
          itself when those unit tests fail.

          (3) Finally, do another round of refactoring to remove any duplication
          introduced to the code or the tests by the addition of the feature.

          Using these three steps, you can incrementally add unit test support to
          your product, which will allow you to have progressively more
          confidence in any additional changes or additions. It may start slow
          at first, but it will build up quickly, probably following an
          exponential rather than linear curve as you eliminate major barriers to
          testability.

          -- Chris

          --
          Chris Hanson, bDistributed.com, Inc. | Email: cmh@...
          Custom Mac OS X Development | Phone: +1-847-372-3955
          http://bdistributed.com/ | Fax: +1-847-589-3738
          http://bdistributed.com/Articles/ | Personal Email: cmh@...
        Your message has been successfully submitted and would be delivered to recipients shortly.