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

Re: [XP] Use Virtual Methods in C++ to Support Fakes?

Expand Messages
  • Ian Collins
    ... This dose work well, I ve used it to mock classes with an abstract base (used to make sure all methods were in the mock). I have also used a trick of not
    Message 1 of 52 , Feb 1, 2006
      kk_oop wrote:

      >Hi. I'm on a C++ project where we are using CppUnitLite to drive our
      >test-driven development.
      >
      >We find that we are using quite a bit of derived "fake" classes. The
      >idea there is that if we are testing class A and it contains an
      >instance of class B, it is helpful to override class B methods to
      >provide fake behavior. Such behavior could simply retain an
      >indication that the method was called (which we can assert on later),
      >or it could return some canned value to force A's method down a
      >certain path.
      >
      >To facilitate the creation of "fakes," we thought it would be a good
      >idea to make all of our class methods virtual. That way, we would be
      >free to make fakes as needed without having to change the production
      >code. Naturally, we can make exceptions to this rule case by case,
      >but it seemed like it would be a good idea to make methods virtual by
      >default.
      >
      >
      >
      This dose work well, I've used it to mock classes with an abstract base
      (used to make sure all methods were in the mock).

      I have also used a trick of not having any inline methods in the class
      header and using tow different implementation files, one for target
      deployment and one linked into the test harness.

      >>From a design perspective, it also seems that virtual methods better
      >support the Open-Closed Principle (OCP), since we could always
      >override existing behavior without touching the currently working
      >production code.
      >
      >Any thoughts for or against making methods virtual by default for
      >these reasons?
      >
      >
      >
      Unless the extra couple of machine cycles for the call is an issue, or
      the classes have to live in shared memory, I can't think of any.

      Ian

      >
      >
      >
      >
      >
    • Randy MacDonald
      ... Good assumption. ... Not so much away from C++ as towards APL. It served me well for two decades, after supposedly dying at least a dozen times. ...
      Message 52 of 52 , Feb 11, 2006
        > On 2/11/06, Randy MacDonald <ramacd@...> wrote:
        > > Given that it's not necessary to paint onesself into such a corner, why
        > > would one do it?
        >
        > I assume this question is rhetorical.

        Good assumption.

        > You seem willing to change jobs to avoid working in C++. Me? I
        > actually fought to choose C++ for certain applications. I don't
        > expect that we'll agree on the subject.

        Not so much away from C++ as towards APL. It served me well for two decades,
        after supposedly dying at least a dozen times.

        -----------------------------------------------------------------------
        |\/| Randy A MacDonald | you can't pay for it,
        |/\| ramacd@... | even if you want to.
        BSc(Math) UNBF'83 Sapere Aude | APL: If you can say it, it's done..
        Natural Born APL'er | Demo website: http://142.166.105.166/
        ----------------------------------------------------(INTP)----{ gnat }-
      Your message has been successfully submitted and would be delivered to recipients shortly.