składnia na NiceMocka ktorego konstruktor ma parametr

0

Czy ktoś zna składnię na to by zrobić NiceMocka w tym przypadku:

class RSMock : public RS
{
public:
    Logger logger;
    RSMock(Logger& _log) :
        RS(_log)
}
///i teraz jak to zainicjować???
Logger logger;
RS* rsM = new ::testing::NiceMock<RSMock>(); //tak by było gdyby konstruktor nie miał parametrów a jak ma?
//to niżej nie działa
Logger logger;
RS* rsM = new ::testing::NiceMock<RSMock>(logger);
0

class RSMock : public RS
{
public:
Logger logger; //poprawka tutaj nie ma tej linijki
RSMock(Logger& _log) :
RS(_log)
}

0

Zastanawia mnie czy by zadziałało coś takiego:

class RSMock : public RS
{
Logger log2;
public:
    RSMock() :
        RS(log2)
}

Pewnie to by było OK, ale jak dodatkowo konstruktor klasy Logger nie jest bezparametrowy (np. przybiera inta) to widzę problem:

class RSMock : public RS
{
Logger log2;
public:
    RSMock() :
        RS(log2),log2(666)
}

Z tego co mi wiadomo to najpierw na liście inicjalizacyjnej zawsze wywoluje się konstruktor klasy po której dziedziczymy a dopiero potem możemy inicjalizowac parametry klasy pochodnej. Czy to prawda?

0

Zrób tak jak należy.
Czyli RS ma wygldać tak:

class IRS {
    virtual jakasMetoda() = 0;
    virtual jakasInnaMetoda(const std::string &text) = 0;
};

class RS : public IRS
{
public:
     RSMock(Logger& _log);

    jakasMetoda();
    jakasInnaMetoda(const std::string &text);
    … … …
};

To co testujesz ma się posługiwać abstrakcją zdefiniowaną przez interface IRS!
Teraz ze zrobienie RSMock nie będzie najmniejszego problemu.


troszkę off topic Straszne są te twoje nazwy domyślam się, że RS to port RS-232, więc ta klasa powinn się nazywać `PortRS232` by unikna nieporozumień i konfliktów nazw! Interface powinien mieć nazwę opisującą funkcjonalność, np: `ICommunitionPort` albo `IAbstractPort` albo `AbstracCommunication` albo ... . Taki interface ma zdefiniowane metody, które są potrzebne by wyklinać zestaw abstrakcyjnych operacji. Nie powinno być istotne, czy to jest RS-232, czy USB, czy LPR czy cokolwiek innego. To jak to zostanie zrealizowane potem jest sprawą drugorzędną. W ten sposób zyskujesz większą elastyczność i prostotę testowania.

1 użytkowników online, w tym zalogowanych: 0, gości: 1