Comments (3)
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
from trompeloeil.
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
from trompeloeil.
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.
from trompeloeil.
Related Issues (20)
- How can i mock a member function of A class in a B class's function? HOT 3
- CMake version required not correct HOT 5
- Setting expectations in a function fails HOT 6
- how can I mock the static member function and non-virtual member fuctions? HOT 2
- Problematic traits for ``streamer`` primary template HOT 4
- Documentation, typo and missing bits and bobs HOT 3
- Compile error when returning values from a tl::expected with a void expected value HOT 5
- Refactoring with sequenced expectations HOT 2
- Build for QNX tests fail due to catch2 header file HOT 1
- Wrong Expectaition message HOT 1
- [Bug] Fails to run tests with catch 3.x HOT 4
- Tests fail to compile: error: 'ret_count' is an unsafe buffer that does not perform bounds checks HOT 4
- Expect call returning a reference HOT 2
- can this cppcheck inline suppression be added HOT 1
- unreal engine support & noreturn/std::abort HOT 3
- Setting side effects after creating expectactions (inside DOCTEST_SUBCASEs) HOT 5
- Feature Request: Allow specifying calling convention attributes to Mock methods HOT 12
- Spy some dependencies HOT 3
- ``trompeloeil_movable_mock`` only provides move-ctor HOT 3
- Warnings with gcc's -Weffc++ HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from trompeloeil.