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
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
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% produkcyjnych
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
![tomaszs - Testowanie rozszerzeń Visual Studio Code cz. 1 [EN]
https://medium.com/@...](https://wykop.pl/cdn/c3201142/comment_1594279485vgk9o0nzpMcUUDoIeS1QKN,w400.jpg)
Chciałbym napisać unit testy dla asynchronicznego klienta MQTT. Załączam link z kodem dla zobrazowania:
godbolt
Klasa Connection docelowo będzie implementacją biblioteki mosquito. Założeniem jest, że klasa połączenia będzie miała wątek przetwarzający operacje asynchroniczne, stąd metoda Run() uruchamiana za wysłaniem requesta o połączenie (tutaj metoda Connect()). Metoda Client::Connect() musi być blokująca ze względu na dalsze wykorzystanie klienta w programie, jednak przez prawdopodobnie zrąbany design dla unit testów nie jestem w stanie wywołać
1. W ciele testu definiujesz promise.
2. Związany z nim future zwracasz z metody Connect().
3. Przy mockowaniu metody Run() musisz zdefiniować akcję która ustawi wartość promise.