[Fitoplankton]

Witam #programowanie
Mam pytanie względem #cpp, #visualstudio i testów. Po dwudniowych bojach z vs w końcu ogarnąłem ten natywny framework testowy ( ͡° ͜ʖ ͡°). I mam teraz pytanie - w jaki sposób powinienem pisać testy? A więc:
1. Dzielenie na pliki - jak? 1 klasa unit testów na plik?
2. Klasy - jak duże? Jaki fragment testowanego kodu powinny zawierać?
3. Metody - wiem, że powinny być niezależne. Ale jak ogarnąć w fajny sposób konstruktor? Tutaj chyba narzuca się, aby na całą klasę był jeden taki ctor, a to implikuje liczbę klas do sporych wartości (i czy z tego powinno wynikać, że konstruktor powinien być możliwie najmniejszy? Np. testuję pierwiastkowanie. Klasą ma być TestyPierwiastkowania, a testami asercje dla danych skrajnych?).

I żeby nie śmiecić zapytam też od razu - chcę napisać symulator maszyny turinga. Czy oparcie interfejsów zewnętrznych (wprowadzanie/wyprowadzanie danych) na abstrakcyjnych klasach będzie ok? Myślałem, żeby potem na potrzeby testów zrobić takie FakeInterfaces, żeby sprawdzać w późniejszych testach zachowanie całego programu. To coś w stylu api? Bo też chciałem zrobić to tak, że sama logika byłaby oddzielnym projektem, który produkowałby dll, który później będzie obsługiwać Qt.

To będzie mój pierwszy tak rozbudowany projekt w cpp, który chciałbym pokazać na rozmowie kwalifikacyjnej (na staż oczywiście). Więc pytanko - do czego powinienem podejść w inny sposób żeby nie narobić sobie wstydu?

[d.....Q]

@Fitoplankton:
Ad1. Każda klasa powinna mieć swoją test suitę. Klasy powinny być spójne logicznie i możliwie jak najmniejsze.
Ad2. Patrz Ad.1
Ad3. Nie bardzo rozumiem... Co rozumiesz przez "ogarną konstruktor"?

Klasy abstrakcyjne są jak najbardziej ok. To o czym piszesz to testowanie oparte na mockach. Generalnie podejście jest takie, że powinieneś testować klasę wyłącznie przez publiczne metody - różne kombinacje z odsłanianiem metod są niebezpieczne i nieeleganckie. Dzięki temu też łatwiejsze jest testowanie

[Fitoplankton]

@dar3Q: w 3. miałem na myśli przygotowanie danych do testu (utworzenie instancji, poustawianiu wartości etc). O TDD czytałem, nawet myślałem, aby w ten sposób to przeprowadzić. Względem googla - to je aktualnie się wykorzystuje? Bo tak grzebałem po stacku i innych serwisach w poszukiwaniu tego najlepszego. I zdania były na tyle podzielone, że poszedłem po najmniejszej linii oporu (przynajmniej na razie). Ale GMock wygląda interesująco, wrzuciłem do przeczytania po wigilii

[d.....Q]

Konstruktor test suity czasem musi być duży, szczególnie jeśli testujesz klasę, w której potrzebujesz wielu mocków. Choć tak jak napisałem, w idealnym świecie Twoje klasy powinny być małe, spójne i łatwe do testowania :) Co do GTesta to tak, jest jak najbardziej wykorzystywany. GMock właściwie jest uzupełnieniem dla niego, umożliwia wykorzystywanie mocków. I jeszcze odnośnie TDD: weź pod uwagę, że tworzenie kodu w ten sposób zazwyczaj trwa więcej czasu, ale za to

[d.....Q]

@Fitoplankton: wołam, bo wcześniej tego nie zrobiłem :)

[Fitoplankton]

@dar3Q: z SOLID spotkałem się już w Clean Code i wziąłem sobie do serca ( ͡° ͜ʖ ͡°). Co do czasożerności TDD - jestem na to przygotowany. Żadne terminy mnie nie gonią, a fajnie byłoby liznąć każdej techniki :)

[C.....m]

swoją test suitę

@dar3Q: boli jak się to czyta (ʘ‿ʘ)

Od siebie polecę również GTest, jakiś tutorial o unit testach i na początek styknie. Testy powinny być możliwie jak najkrótsze i (w unit testach) powinieneś każdą funkcjonalność osobno testować, a nie wszystko w jednym teście. Każdy test powinien jedną rzecz tylko sprawdzać i nie polegać (idealnie) na żadnych innych.

[d.....Q]

@CoJaCzytam: Dlaczego boli?

[C.....m]

@dar3Q: bo trochę "nie po polskiemu" ;) lepiej by brzmiał zestaw testów albo coś takiego ;)

[d.....Q]

@CoJaCzytam: Cała ta branża jest trochę "nie po polskiemu" :) Nikt nie mówi 'zestaw testów', za to 'test suita' prawie każdy. Też mnie czasem wkurza nadużywanie anglicyzmów w języku potocznym, ale w środowisku programistów raczej tego nie unikniemy :)