Setting side effects after creating expectactions (inside DOCTEST_SUBCASEs) about trompeloeil HOT 5 CLOSED

Also, one more thing: I'm having problems with telling my MyApp to quit. It has an exit() method, so if I could somehow know when all the expectations get fullfilled, I could just call it. Or, if I could attach side effects to existing expectations, I could just do this:

MyApp app(mock);
expectations.back().add_lr_side_effect(app.exit());
app.exec();

from trompeloeil.

I'm really not very familiar with doctest, and I'm not at all sure how subcases work.

What I think you can do is to create a separate collection of side effects that you want to run, and you set your expectation's .SIDE_EFFECT() to run all of them. Then you can add to, and subtract from, that collection in your subcases.

Something like this:

DOCTEST_TEST_CASE("MyTest")
{
	auto mock = new MockInterface();
	std::vector<std::unique_ptr<trompeloeil::expectation>> expectations;
        std::list<std::function<void()>> side_effects;
	auto init_expectation = NAMED_REQUIRE_CALL(*mock, init())
                                .LR_SIDE_EFFECT(for (auto& f : side_effects) { f(); });

	DOCTEST_SUBCASE("someMethod") {
                auto i = side_effects.insert(side_effects.end(), [&](){ /* blah */ });
                // work
                side_effects.erase(i);
	}

	DOCTEST_SUBCASE("otherMethod") {
                auto i = side_effects.insert(side_effects.end(), [&](){ /* bleh */ });
                // other work
                side_effects.erase(i);
	}

	// After setting up all the expectations, actually run the app.
	MyApp app(mock);
	// exec blocks until the app closes.
	app.exec();
}

For your latter problem, you can query in expectation if it is satisfied or not. See https://github.com/rollbear/trompeloeil/blob/main/docs/reference.md#is_satisfied. Although, I do find it very odd that your test program doesn't know when the unit under test has reached it's conclusion.

from trompeloeil.

The point of DOCTEST_SUBCASE is that for every leaf subcase, the test is run exactly once, and every iteration it changes the "current" leaf. The advantage is that you can reuse the init/common code outside of the subcases.

What I think you can do is to create a separate collection of side effects that you want to run, and you set your expectation's .SIDE_EFFECT() to run all of them. Then you can add to, and subtract from, that collection in your subcases.

This is more or less what I do in my last code example:

std::function<void()> fn;
auto init_expectation = NAMED_REQUIRE_CALL(*mock, init()).LR_SIDE_EFFECT(fn());

DOCTEST_SUBCASE("someMethod") {
	fn = invoke_side_effect_for_someMethod;
	expectations.emplace_back(NAMED_REQUIRE_CALL(*mock, someMethod()));
}

just with a single function, without a list. It's a fine solution, I don't mind using that, I just thought that maybe there could be a way to somehow set the side effect "in runtime", as in, use .LR_SIDE_EFFECT after the expectation has been created. But I understand, that it might not be possible given how many checks are in the macros (and I guess they are compile time checks).

For your latter problem, you can query in expectation if it is satisfied or not. See https://github.com/rollbear/trompeloeil/blob/main/docs/reference.md#is_satisfied.

I can't do this because after I run .exec() I can only run code inside side effects.

Although, I do find it very odd that your test program doesn't know when the unit under test has reached it's conclusion.

The way my program works is that I run it via .exec(), then it starts listening for events, and responds to them. The app itself doesn't know that it's being tested. The tests do not do anything until after I run .exec(), because the test code is in the side effects, and expectations. After all the expectations are satisfied, the app continues to run, because no one told it, it should stop. Another idea: maybe trompeloeil coud expose some sort of a callback mechanism, that would notify me, whenever an expectation is completed?

This is maybe bending trompeloeil (and doctest) too much, and my method of testing might be a little weird. Unfortunately, I haven't found of a better way to test apps that have an event loop, than define a bunch of expectations and attach side effects beforehand, and then run the app and let it do its thing. But of course I understand that figuring out how to test my app isn't in the scope of this project.

from trompeloeil.

It's doable, I think, but it seems like a lot of work for a very special case that is quite easy to achieve anyway.

from trompeloeil.

Okay, no worries. I thought it wouldn't be so easy. I'm closing this, but feel free to reopen, if you want to track this somehow.

from trompeloeil.