There are some merge markers in added file 'tests/test_launcher_controller.cpp'.
General comments:
* If you want to avoid the friend declaration, you can do something like this:
class TestLauncherExpectationsInterface
{
public:
virtual void ExpectNumControllers (int num) = 0;
...
}
This method is pretty ugly though, and the friend might be better. Generally speaking, testing implementation details isn't really recommended, but in this case we want to do that.
* Its a bit unclear as to how UScreen.SetupFakeMultimonitor () causes more launchers to be added to an lc it doesn't know about, unless some singleton knows about lc, and that's pretty confusing.
Looks good.
There are some merge markers in added file 'tests/ test_launcher_ controller. cpp'.
General comments:
* If you want to avoid the friend declaration, you can do something like this: ectationsInterf ace llers (int num) = 0;
class TestLauncherExp
{
public:
virtual void ExpectNumContro
...
}
LauncherCont rollerPrivate: :SetExpectation s (TestLauncherEx pectationsInter face *expect)
expect- >ExpectNumContr ollers (whatever);
{
...
}
::testing: :NiceMock <MockLauncherEx pectations> mock_launcher_ expectations;
EXPECT_CALL (mock_launcher_ expectations, ExpectNumContro llers (value));
This method is pretty ugly though, and the friend might be better. Generally speaking, testing implementation details isn't really recommended, but in this case we want to do that.
* Its a bit unclear as to how UScreen. SetupFakeMultim onitor () causes more launchers to be added to an lc it doesn't know about, unless some singleton knows about lc, and that's pretty confusing.