[Parseval]

Hey,

Ostatnio podczas pisania unit testów naszło mnie na refleksje i mam przeczucie, że spierniczyłem design projektu, ale do rzeczy. Stworzyłem strukturę gdzie foldery są podzielone na funkcjonalności, a w każdym takim folderze są pliki źródłowe i CMakeLists tworzący z nich bibliotekę, która linkowana jest do głównego targetu projektu. Załóżmy, że istnieje klasa MqttClient i klasa MqttConnection, która impelemntuje interfejs. W unit testach tworzę mocka tego interfejsu co jest oczywiste, ale pojawia się problem, żeby do głównego targetu testów dolinkować wcześniej wspomnianą bibliotekę z uwagi na to, że ona kompiluje implementację tego interfejsu czego w testach być nie powinno. Aktualnie rozwiązałem sprawę tak, że pod folderem testów tworzę bliźniaczy folder do tego z wcześniejszą biblioteką, ale bez konkretnej implementacji interfejsu. Mam wrażenie, że to rozwiązanie stwarza pewien narzut, a nie chciałbym do cmaków tych bibliotek dodawać logiki typu if (tests). Czy można to rozwiązać w lepszy sposób?

#cpp #programista15k #programowanie #cmake #unittest #gtest

[zibizz1]

@Parseval: Przecież to oczywiste ze jak inne projekty mają korzystac z interfejsów to powinny one byc w osobnym projekcie.

Implementacja -> Interfejsy <- Testy

[Saly]

MqttClient i klasa MqttConnection, która impelemntuje interfejs. W unit testach tworzę mocka tego interfejsu co jest oczywiste, ale pojawia się problem, żeby do głównego targetu testów dolinkować wcześniej wspomnianą bibliotekę z uwagi na to, że ona kompiluje implementację tego interfejsu czego w testach być nie powinno.

@Parseval: nie ma czegoś takiego, że "w testach tego być nie powinno". Testujesz tak jak uważasz, że jest stosownie. Testowanie interfejsu, który w 100%

[WyjmijKija]

@Parseval: przeczytałem 1/3 posta i już po tym jestem przekonany, że nie mogłeś nie spierniczyć designu projektu. Mam nadzieję, że pomogłem.

[SpinOff]

@Parseval Jaką masz strukturę katalogów testowych? Każdy moduł ma swój folder tests?

[Tytanowy]

@Parseval: Trochę już nie myślę o tej porze, więc muszę dopytać. Chodzi o to, że testujesz moduł, którzy korzysta z Mqtt, więc potrzebujesz interfejs z innego CMakowego targetu aby go zamockować? Ponadto obawiasz się, że niepotrzebnie linkujesz implementację skoro potrzebujesz tylko nagłówka?

Jeżeli testujesz samo Mqtt to imo testy każdego modułu powinny się znajdować wewnątrz modułu.

Jeżeli testujesz inny moduł, który korzysta z modułu Mqtt to przecież ten testowany moduł musi mieć podlinkowane Mqtt, więc testy również będą mogły z tego

[Parseval]

@Saly Jasna sprawa, nie chcę testować samego interfejsu tylko MqtrClient. Interfejs jest zamockowany i przez mocka ustawiam jakie wartości ma zwracać itd.

@SpinOff Nie, mam jeden folder tests pod którym mam pliki z testami do modułów i foldery z cmakami, które są okrojone o źródła implementacji interfejsów.

@Tytanowy Nie do końca, chodzi głównie o niepotrzebne linkwoanie implementacji. Możliwe, że INTERFACE z cmake może pomóc, muszę poczytać. Dzięki!

[Saly]

@Parseval: rozwiązania widzę dwa: olanie sprawy albo dwie niezależne biblioteki: jedna to interfejs a jedna to implementacja interfejsu. Robienie czegoś po środku to proszenie się o kłopoty i i granie z bebechami tego jak w C++ buduje się apki

[Saly]

Nie, mam jeden folder tests pod którym mam pliki z testami do modułów i foldery z cmakami, które są okrojone o źródła implementacji interfejsów.

@Parseval: trochę słabo, testy powinny być przy module. Dobrą metryką modularności jest ile folderów muszę przenieść, żeby przenieść cały moduł do innego projektu. Jak wszystko siedzi w jednym folderze/podfolderach odpowiedzialnych za dany moduł to jest idealnie

[Parseval]

@Saly dzięki za radę, na szczęście jest to start projektu, więc zrobię jak napisałeś.