OK to avoid interfaces, virtuals, pointers, compiling in mocked-out library, like this?

[jamespharvey20]

Figures after working on this for a long time, just after I submitted the original 2 posts, it would hit me to have a global api variable, as you did in your most recent post on issue 18. So I'm changing my post from asking if there's a way to act this way, to asking if there's anything wrong with how I'm implementing it. Seems to work in this small example.

I'm a bit worried about whether a global api variable is OK, or if things could leak between tests. I'm not familiar with how globals are handled in catch, and if trompeloeil when exiting a test's scope forgets everything in there.

So, you should be able to skip post 2 entirely, and go onto post 3, unless you say post 3 is bad.

In short, I have a class encapsulates which is what I'm testing. It has a private member variable of class beingMocked. In pre-mocking code, there's no inheritance, no virtual functions, and no pointers, which I like very much.

Below is the pre-mocking code.

beingMocked.h

#ifndef BEING_MOCKED_H
#define BEING_MOCKED_H

class beingMocked {
public:
   beingMocked(int tA);
   void p();
private:
   int a;
};

#endif

beingMocked.cpp

#include <beingMocked.h>
#include <iostream>

beingMocked::beingMocked(int tA)
   : a{tA} {
}

void beingMocked::p() {
   std::cout << "beingMocked::p()" << endl;
}

encapsulates.h

#ifndef ENCAPSULATES_H
#define ENCAPSULATES_H

#include <beingMocked.h>

class encapsulates {
public:
   encapsulates(int tA);
private:
   beingMocked internal;
};

#endif

encapsulates.cpp

#include <encapsulates.h>

encapsulates::encapsulates(int tA)
   : internal{tA} {
   internal->p();
}

production.cpp

#include <encapsulates.h>

int main() {
   encapsulates x { 2 };
}

building

g++ -I. beingMocked.cpp -c -o beingMocked.o
g++ -I. encapsulates.cpp -c -o encapsulates.o
g++ -I. -I<<trompeloeil include directory>> production.cpp beingMocked.o encapsulates.o -o production

[jamespharvey20]

Can skip this, to post 3, unless you say post 3 is a bad idea.

Originally -- I was wondering if you could say if there's any simplifications you'd make to using trompeloeil in this multi file skeleton examples.

Few things I really wish were different, but recognize now it's probably the cost of unit testing and mocking. Hoping there's some type of trompeloeil-foo that I've missed.

What I'd love is to have production and unit test/mock code use beingMocked.h. Production code uses beingMocked.cpp/.o. Unit test/mock code just implements the already defined f

(1) I think I misunderstood the ability to not inherit a mock class from an interface. Does that just mean totally new classes, such as the c function seaming?) Or have I missed a way to inherit from a instantiatable non-interface class, without virtuals and just hide base class implementation with new functions?

(2) Likewise, since encapsulates is going to "keep" beingMocked, rather than being given it on every call (many member functions omitted, and as shown production code doesn't even have to make and give it), have I missed a way to use a reference rather than a pointer for beingMocked? I couldn't find a way to make polymorphic references work here, even with moves and rvalue moves. (I'm talking about references to stack (statically) allocated variables, not heap (dynamically) allocated ones, so there wouldn't be slicing.)

(3) Have I missed any way to omit giving beingMocked.o when compiling mockTest? I had hoped I could include the beingMocked.h, omit the actual implementation, and just slide in the trompeloeil implementation. Omitting beingMocked.o gives encapsulates.cpp: undefined reference to beingMocked::beingMocked(int). This is coming from the encapsulates(int) constructor which is never used in mockTest, only production. Although it should never actually get called, it would be even more sure if it was never included.

Below is the mocked code.

(NEW) beingMockedInterface.h

#ifndef INTERFACE_H
#define INTERFACE_H

class beingMockedInterface {
public:
   virtual ~beingMockedInterface() { }
   virtual void p() = 0;
};

#endif

beingMocked.h

#ifndef BEING_MOCKED_H
#define BEING_MOCKED_H

#include <beingMockedInterface.h>

class beingMocked : public beingMockedInterface {
public:
   beingMocked(int tA);
   virtual ~beingMocked() {}
   virtual void p() override;
private:
   int a;
};

#endif

beingMocked.cpp

<unchanged>

encapsulates.h

#ifndef ENCAPSULATES_H
#define ENCAPSULATES_H

#include <beingMocked.h>

#include <memory>
using namespace std;

class encapsulates {
public:
   encapsulates(unique_ptr<beingMockedInterface>&& tInternal);
   encapsulates(int tA);
private:
   unique_ptr<beingMockedInterface> internal;
};

#endif

encapsulates.cpp

#include <encapsulates.h>

#include <memory>
using namespace std;

encapsulates::encapsulates(unique_ptr<beingMockedInterface>&& tInternal)
   : internal { move(tInternal) } {
   internal->p();
}

encapsulates::encapsulates(int tA)
   : internal { new beingMocked{tA} } {
   internal->p();
}

production.cpp

<unchanged>

(NEW) mockTest.cpp

#include <trompeloeil.hpp>
using namespace trompeloeil;

#include <encapsulates.h>

#include <memory>
#include <iostream>
using namespace std;

class beingMockedAPI : public beingMockedInterface {
public:
   MAKE_MOCK0(p, void(), override);
};


int main() {
   unique_ptr<beingMockedAPI> ptr { make_unique<beingMockedAPI>() };
   REQUIRE_CALL(*ptr, p())
      .SIDE_EFFECT(cout << "beingMockedAPI::p()" << endl);
   encapsulates y { move(ptr) };
}

building

g++ -I. beingMocked.cpp -c -o beingMocked.o
g++ -I. encapsulates.cpp -c -o encapsulates.o
g++ -I. -I<<trompeloeil include directory>> production.cpp beingMocked.o encapsulates.o -o production
g++ -I. -I<<trompeloeil include directory>> mockTest.cpp beingMocked.o encapsulates.o -o mockTest

[jamespharvey20]

I may have found the style I like best. Looking at how I implement the mocking and unit tests in this reply, do you see anything that jumps out as problematic? So, ignoring my second post on this issue, and just adding this file to the ones in the first post on this issue.

mockTest.cpp

#define CATCH_CONFIG_MAIN
#include <catch.hpp>

#include <trompeloeil.hpp>
using namespace trompeloeil;

#include <encapsulates.h>

#include <iostream>
using namespace std;

class API {
public:
   MAKE_MOCK1(constructor, void(int));
   MAKE_MOCK0(p, void());
};

static API api;

// seam the missing beingMocked.o

beingMocked::beingMocked(int tA) {
   api.constructor(tA);
}

void beingMocked::p() {
   api.p();
}


TEST_CASE("a") {
   REQUIRE_CALL(api, constructor(eq(5)));
   REQUIRE_CALL(api, p())
      .SIDE_EFFECT(cout << "beingMockedAPI::p()" << endl);
   encapsulates x { 5 };
}

TEST_CASE("b") {
   REQUIRE_CALL(api, constructor(eq(5)));
   REQUIRE_CALL(api, p())
      .SIDE_EFFECT(cout << "beingMockedAPI::p()" << endl);
   encapsulates x { 5 };
}

building

g++ -I. beingMocked.cpp -c -o beingMocked.o
g++ -I. encapsulates.cpp -c -o encapsulates.o
g++ -I<<trompeloeil include directory>> production.cpp beingMocked.o encapsulates.o -o production
g++ -I<<trompeloeil include directory>> mockTest.cpp encapsulates.o -o mockTest

[rollbear]

It's a matter of taste, of course. I think I like the unique_ptr<> version more than communicating via an API. The latter effectively is a singleton which makes life a bit more difficult in general, and especially if you need several instances of encapsulates. However, there are down sides to communicating via an interface too.

Another variant, that may or may not be usable for you, is to make a template out of encapsulates.

template <typename M>
class encapsulates_t
{
public:
  encapsulates_t(int num) : a(num) { a.p();}
private:
  M a;
};

using encapsulates = encapsulates_t<beingMocked>;

This gives you freedom to test encapsulates_t with whatever you feel like.