Testowanie jednostkowe kodu obciążającego efekt uboczny

Zaczynam pisać kod C ++, aby uruchomić robota, i nie wiem, jak włączyć testowanie jednostkowe, jeśli rzeczywiście mogę. Dostałem bibliotekę, która pozwala na tworzenie „poleceń” dla robota, które są automatycznie planowane i wykonywane. Mechanizm tworzenia tych poleceń jest podklasy klasy bazowej polecenia ich dostarczania i wprowadzania wirtualnych void Initialize(), void Execute()i void End()metod. Funkcje te są uruchamiane wyłącznie ze względu na ich skutki uboczne, które działają na robota (uruchamianie silników, wysuwanie tłoków itp.). Z tego powodu tak naprawdę nie widzę nigdzie, aby dołączyć testy jednostkowe do kodu, poza wyśmiewaniem całej biblioteki, abym mógł sprawdzić wirtualność przed i po stanach robota. Czy istnieje sposób na przetestowanie tego urządzenia, które nie jest zbyt uciążliwe?

Edytować

Myślę, że mogłem wprowadzać w błąd co do funkcjonalności biblioteki. Biblioteka zapewnia większość interfejsu dla robota, a także system poleceń / planowania, więc nie jest to tak proste jak wyśmiewanie podstawowej klasy poleceń, musiałbym wyśmiewać cały interfejs do sprzętu. Niestety nie mam na to czasu.

W tym przypadku chciałbym wprowadzić własny interfejs RobotControl z metodami odpowiadającymi tym z prawdziwej biblioteki.

Po wykonaniu tej czynności utworzę klasę RobotControlImpl, która implementuje ten interfejs w stosunku do prawdziwej biblioteki lib.

Polecenia, które w konsekwencji napisałbym, nie rozszerzyłyby klasy podstawowej, lecz działałyby na interfejsie, który wprowadziłeś.

W ten sposób możesz wyśmiewać RobotControl, przekazać próbkę do dowolnej komendy i sprawdzić, czy wywołała ona odpowiednie metody interfejsu.

W prod przekazałbyś prawdziwy implant RobotControl do zaimplementowanych poleceń.

Nie jestem pewien, czy to właśnie miałeś na myśli i uważałeś za kłopotliwy?

Edycja: Aha, a jeśli oczekujesz, że polecenia będą spać, aby poczekać na zakończenie (koszmar, ale czasami to właśnie masz), wymagam, aby polecenia wywoływały metodę uśpienia na RobotControl. W ten sposób możesz wyłączyć uśpienia podczas testu i po prostu sprawdzić, czy polecenie próbuje zasnąć.

Myślę, że można sprawić, by kod był testowalny w minimalnie inwazyjny sposób. Rozumiem przez to, że możesz pisać polecenia dokładnie tak, jak zamierzają autorzy biblioteki robotów. Może to być korzystne, jeśli chcesz wymieniać kod z innymi, którzy nie używają twojej warstwy pośredniej.

Wymaga osobnej „kompilacji testu jednostkowego” kodu.

To, co robisz, polega na tym, że w jednym centralnym pliku nagłówkowym sprawdzasz czas kompilacji i określasz, czy jest to kompilacja testu jednostkowego, a jeśli tak, to na nowo definiuje nazwę klasy podstawowej, a może niektóre inne klasy w bibliotece robotów na nazwy klas twojej implementacji testowej. Powinieneś zdefiniować te same funkcje wirtualne jak w lib robota, a także dostarczyć kody pośredniczące dla metod, które wywołujesz na robocie.

Następnie masz komendy, które możesz wrzucić do własnej struktury testowej, która wywołuje te same metody, które zrobiłaby biblioteka robotów.

Będzie to wymagało pewnego karczowania i kpin, ale jest to nieuniknione w każdym projekcie testu jednostkowego.

Zmiana nazwy klasy podstawowej może być wykonana za pomocą #define lub prawdopodobnie preferowanego, typedef.