Czy metody prywatne / chronione powinny być poddawane testom jednostkowym?

83

W programowaniu TDD pierwszą rzeczą, którą zwykle robisz, jest utworzenie interfejsu, a następnie rozpoczęcie pisania testów jednostkowych w odniesieniu do tego interfejsu. W miarę postępów w procesie TDD skończyłoby się na utworzeniu klasy, która implementuje interfejs, a następnie w pewnym momencie test jednostkowy przeszedłby.

Teraz moje pytanie dotyczy prywatnych i chronionych metod, które być może będę musiał napisać w mojej klasie w celu wsparcia metod / właściwości udostępnianych przez interfejs:

  • Czy metody prywatne w klasie powinny mieć własne testy jednostkowe?

  • Czy chronione metody w klasie powinny mieć własne testy jednostkowe?

Moje myśli:

  • Zwłaszcza, że ​​koduję do interfejsów, nie powinienem martwić się o metody chronione / prywatne, ponieważ są to czarne skrzynki.

  • Ponieważ używam interfejsów, piszę testy jednostkowe, aby sprawdzić, czy zdefiniowany kontrakt jest prawidłowo zaimplementowany przez różne klasy implementujące interfejs, więc ponownie nie powinienem martwić się o metody prywatne / chronione i powinny być wykonywane za pomocą testów jednostkowych, które wywołują metody / właściwości zdefiniowane przez interfejs.

  • Jeśli pokrycie mojego kodu nie pokazuje, że metody chronione / prywatne są trafione, oznacza to, że nie mam odpowiednich testów jednostkowych lub mam kod, który nie jest używany i powinien zostać usunięty.

Raj Rao
źródło
1
Jeśli nie korzystasz z metod chronionych z testów, zastępując je lub wywołując je, dlaczego są one chronione, a nie prywatne? Zabezpieczając je, podejmujesz świadomą decyzję o ujawnieniu punktu rozszerzenia / funkcjonalności. Dla mnie, jeśli śledzisz TDD, ta decyzja powinna być podyktowana testami, które piszesz.
forsvarir
2
Część dotyczącą własnych myśli powinieneś umieścić w osobnej odpowiedzi. Daj mi znać, kiedy to zrobisz, a zagłosuję za.
Keith Pinson
To samo dotyczy tylko osób prywatnych: stackoverflow.com/questions/105007/…
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
Masz rację co do aktywnych testów jednostkowych, tj. Tych, które są skonfigurowane do ciągłego działania. W tym celu chcesz przetestować tylko publiczne i chronione interfejsy. Możesz i przydałby się również napisanie testów na metody prywatne. Testy te nie powinny być częścią twojego zestawu ciągłego, ale jako jednorazowe sprawdzenie, czy implementacja jest dobra, może być bardzo cennym narzędziem.
Didier A.

Odpowiedzi:

109

Nie, nie myślę o testowaniu metod prywatnych lub chronionych. Prywatne i chronione metody klasy nie są częścią interfejsu publicznego, więc nie ujawniają publicznego zachowania. Generalnie te metody są tworzone przez refaktoryzacje, które stosujesz po tym, jak Twój test zmieni kolor na zielony.

Więc te prywatne metody są testowane niejawnie przez testy, które potwierdzają zachowanie twojego interfejsu publicznego.

Mówiąc bardziej filozoficznie, pamiętaj, że testujesz zachowanie, a nie metody. Więc jeśli pomyślisz o zestawie rzeczy, które może zrobić testowana klasa, o ile możesz przetestować i potwierdzić, że klasa zachowuje się zgodnie z oczekiwaniami, czy istnieją prywatne (i chronione) metody, które są używane wewnętrznie przez klasę do implementacji to zachowanie jest nieistotne. Te metody są szczegółami implementacji zachowania publicznego.


źródło
23
Podoba mi się fakt, że powiedziałeś, że testy jednostkowe, testują zachowanie, a nie metody! To bardzo wyjaśnia sprawę.
Raj Rao,
1
Zgadzam się z @rajah. To powinno być pierwsze stwierdzenie w każdym samouczku. Zastanawiałem się, jak przetestować moje metody, teraz wiem, że nie muszę. +1
mroźny cudowny
3
Czy powiedziałbyś, że nadal ma to zastosowanie w przypadkach, gdy klasy bazowe implementują chronione zachowanie, które społeczeństwo powinno dziedziczyć i używać? Zatem metody chronione nadal są częścią interfejsu publicznego, czyż nie?
Nick Udell
1
Ogólnie rzecz biorąc, wzorce sprzyjające rozdzielaniu problemów są bardziej odpowiednie do izolowanych testów jednostkowych, podczas gdy wzorce sprzyjające hermetyzacji mają łatwiejsze w użyciu interfejsy API.
尤川豪
3
Nie wyjaśnia to przypadku chronionej widoczności. Wygląda na to, że chroniona metoda jest również częścią interfejsu, często jest to punkt rozszerzenia, celowo zabezpieczony jako taki. Powiedziałbym, że w takich przypadkach należy je również przetestować jednostkowo. Nie chcesz, aby ktokolwiek zmieniał rzeczy w przyszłości i łamał klasy, które zależały od tych punktów rozszerzenia dla zachowania.
Didier A.
47

Nie zgadzam się z większością plakatów.

Najważniejsza zasada to: KOD ROBOCZY PRZERWA TEORETYCZNE ZASADY dotyczące publicznego / chronionego / prywatnego.

Twój kod powinien zostać dokładnie przetestowany. Jeśli możesz się tam dostać, pisząc testy dla metod publicznych, które wystarczająco ćwiczą metody chronione / prywatne, to świetnie.

Jeśli nie możesz, albo refaktoryzuj, abyś mógł, albo nagnij chronione / prywatne reguły.

Jest świetna historia o psychologu, który dał dzieciom test. Dał każdemu dziecku dwie drewniane deski z liną przymocowaną na każdym końcu i poprosił je, aby przeszły przez pokój bez dotykania podłogi tak szybko, jak to możliwe. Wszystkie dzieci używały desek jak małych nart, po jednej nodze na każdej desce, trzymając je za liny i ślizgając się po podłodze. Następnie dał im to samo zadanie, ale używając tylko JEDNEJ planszy. Obracali się / „szli” po podłodze, po jednej nodze na każdym końcu pojedynczej deski - i byli SZYBSZY!

To, że Java (lub jakikolwiek inny język) ma jakąś funkcję (prywatną / chronioną / publiczną), niekoniecznie oznacza, że ​​piszesz lepszy kod, ponieważ go używasz!

Teraz zawsze będzie można zoptymalizować / zminimalizować ten konflikt. W większości języków możesz uczynić metodę chronioną (zamiast publiczną) i umieścić klasę testową w tym samym pakiecie (lub czymkolwiek), a metoda będzie dostępna do testowania. Istnieją adnotacje, które mogą pomóc, opisane na innych plakatach. Możesz użyć refleksji, aby dostać się do prywatnych metod (fuj).

Liczy się również kontekst. Jeśli piszesz API do użytku przez osoby z zewnątrz, ważniejsze jest publiczne / prywatne. Jeśli to projekt wewnętrzny - kogo to naprawdę obchodzi?

Ale pod koniec dnia zastanów się, ile błędów spowodował brak testów. Następnie porównaj z liczbą błędów spowodowanych metodami „nadmiernie widocznymi”. Ta odpowiedź powinna wpłynąć na twoją decyzję.

Charles Roth
źródło
3
Jeśli metoda jest krytyczna i ma skomplikowaną logikę, stwierdzenie jej zachowania jest bardzo przydatne w zapobieganiu błędom. Napisanie testu jednostkowego dla takiej metody może nawet pomóc, ponieważ implementujesz tę metodę w sposób eksploracyjny. Więc nawet jeśli jest prywatny, powiedziałbym, że warto go przetestować. ALE, i jest duży, ale musisz pamiętać, że testy są sprzężeniem kodu. Jeśli piszesz test do metody, zapobiegasz refaktoryzacji.
Didier A.
6
Więc zanim zaczniesz pisać testy dla metod prywatnych, powiedziałbym, że zawsze przemyśl swój projekt. Zobacz, czy rzeczy można uogólnić i przekształcić w czyste metody funkcjonalne. Jeśli tak, możesz wyodrębnić je do własnej konstrukcji. Ta konstrukcja może następnie mieć swój własny interfejs publiczny i zostać przetestowana jednostkowo. Pamiętaj, że często skomplikowane zachowanie w metodach prywatnych może oznaczać, że klasa ma więcej niż jedną odpowiedzialność. Więc proszę, najpierw przemyśl swój projekt.
Didier A.
Tak, ale co to jest „działający kod”? Testowanie metody prywatnej nie mówi nic o tym, czy twój obiekt zachowuje się prawidłowo. To jest główny powód, dla którego testujemy tylko metody publiczne. Tylko metody publiczne wykazują zachowanie, o które dba użytkownik fragmentu kodu.
Sammi
1
„Kod roboczy” to kod, który działa. Jeśli w Twojej metodzie prywatnej (lub quasi-prywatnej) jest błąd, którego nie wychwycą testy metod publicznych, coś jest nie tak. Może twój projekt jest zły, wystarczająco uczciwy: zgadzam się, że najlepszym rozwiązaniem są testy, które wywołują metody publiczne. Ale nie zawsze jest to możliwe, zwłaszcza jeśli dodajesz lub naprawiasz starszy kod. (Mówię z doświadczenia, o projekcie zawierającym 1 milion wierszy kodu). Testowany kod jest zawsze lepszy niż nieprzetestowany kod, kropka. Nawet jeśli złamiemy niezłe zasady dotyczące testowania tylko metod publicznych!
Charles Roth
Fragment (u góry) dotyczący „testów to sprzężenie kodu… zapobieganie refaktoryzacji” jest w 100% błędny. W metaforze architektonicznej testy to rusztowanie, a nie beton. Rzeczy się zmieniają, testy się zmieniają, zostają wyrzucone, powstają nowe testy. Zgadzam się, że dobry projekt minimalizuje konieczność przepisywania testów. Ale zdarzają się zmiany, nawet w najlepszych projektach.
Charles Roth
35

Napisałeś:

W programowaniu TDD pierwszą rzeczą, którą zwykle robisz, jest utworzenie interfejsu, a następnie rozpoczęcie pisania testów jednostkowych w odniesieniu do tego interfejsu. W miarę postępów w procesie TDD skończyłoby się na utworzeniu klasy, która implementuje interfejs, a następnie w pewnym momencie test jednostkowy przeszedłby.

Pozwól, że przeformułuję to w języku BDD :

Opisując, dlaczego klasa jest cenna i jak się zachowuje, pierwszą rzeczą, którą zazwyczaj robisz, jest utworzenie przykładu użycia klasy, często za pośrednictwem jej interfejsu *. Dodając pożądane zachowanie, tworzysz klasę, która zapewnia tę wartość, a następnie w pewnym momencie twój przykład działa.

* Może być rzeczywistym Interfacelub po prostu dostępnym API klasy, np .: Ruby nie ma interfejsów.

Dlatego nie testujesz metod prywatnych - ponieważ test jest przykładem tego, jak używać tej klasy i nie możesz ich właściwie używać. Coś, co możesz zrobić, jeśli chcesz, to delegowanie obowiązków w metodach prywatnych do klasy współpracującej, a następnie mock / stub tego pomocnika.

W przypadku metod chronionych mówisz, że klasa, która rozszerza twoją klasę, powinna mieć określone zachowanie i zapewniać pewną wartość. Następnie możesz użyć rozszerzeń swojej klasy, aby zademonstrować to zachowanie. Na przykład, jeśli piszesz uporządkowaną klasę kolekcji, możesz chcieć zademonstrować, że dwa rozszerzenia o tej samej zawartości wykazały równość.

Mam nadzieję że to pomoże!

Lunivore
źródło
1
Genialny post. Wiele wyjaśnia.
mroźno cudowny
17

Kiedy piszesz testy jednostkowe dla swojej klasy, nie musisz koniecznie dbać o to, czy funkcjonalność klasy jest implementowana bezpośrednio w metodzie w interfejsie publicznym, czy też jest zaimplementowana w szeregu metod prywatnych. Więc tak, powinieneś testować swoje metody prywatne, ale nie powinieneś w tym celu wywoływać ich bezpośrednio z kodu testowego (bezpośrednie testowanie metod prywatnych ściśle łączy Twoją implementację z testami i sprawia, że ​​refaktoryzacja jest niepotrzebnie trudna).

Metody chronione tworzą inny kontrakt między twoją klasą a jej przyszłymi elementami podrzędnymi, więc naprawdę powinieneś testować je w podobnym stopniu jak interfejs publiczny, aby upewnić się, że kontrakt jest dobrze zdefiniowany i wykonywany.

forsvarir
źródło
13

Nie! Tylko interfejsy testowe.

Jedną z dużych zalet TDD jest zapewnienie, że interfejs działa bez względu na to, w jaki sposób zaimplementowałeś metody prywatne.

S.Lott
źródło
11

Kończąc to, co powiedzieli inni powyżej, powiedziałbym, że metody chronione są częścią pewnego rodzaju interfejsu: po prostu tak się składa, że ​​jest to narażone na dziedziczenie, a nie na kompozycję, o czym każdy myśli, rozważając interfejsy.

Oznaczanie metody jako chronionej zamiast prywatnej oznacza, że ​​oczekuje się, że będzie ona używana przez kod strony trzeciej, więc należy zdefiniować i przetestować jakiś rodzaj umowy, jak to ma miejsce w przypadku normalnych interfejsów zdefiniowanych przez metody publiczne, które są otwarte zarówno na dziedziczenie, jak i na kompozycję .

FGM
źródło
9

Istnieją dwa powody, dla których warto pisać testy:

  1. Zapewnianie oczekiwanego zachowania
  2. Zapobieganie regresji zachowań

Podejście (1) Zapewnienie oczekiwanego zachowania:

Podczas potwierdzania oczekiwanego zachowania chcesz się upewnić, że kod działa tak, jak myślisz, że powinien. Jest to w rzeczywistości zautomatyzowany sposób wykonywania rutynowej ręcznej weryfikacji, którą każdy programista wykonałby podczas implementacji dowolnego rodzaju kodu:

  • Czy to, co właśnie napisałem, działa?
  • Czy ta pętla faktycznie się kończy?
  • Czy zapętla się w kolejności, w jakiej myślę, że jest?
  • Czy to zadziała dla zerowego wejścia?

To są pytania, na które wszyscy odpowiadamy w naszych głowach i zwykle próbujemy wykonać kod również w naszych głowach, upewniając się, że wygląda na to, że działa. W takich przypadkach często warto poprosić komputer o udzielenie ostatecznej odpowiedzi. Więc piszemy test jednostkowy, który zapewnia, że ​​tak. Daje nam to zaufanie do naszego kodu, pomaga nam wcześnie znajdować usterki, a nawet może pomóc w faktycznym wdrożeniu kodu.

Warto to zrobić wszędzie tam, gdzie uważasz, że jest to konieczne. Każdy kod, który jest trochę trudny do zrozumienia lub nietrywialny. Nawet trywialny kod mógłby na tym skorzystać. Chodzi o twoją własną pewność siebie. To, jak często to robisz i jak daleko zajdziesz, zależy od twojej własnej satysfakcji. Przestań, kiedy możesz śmiało odpowiedzieć Tak na: Czy na pewno to działa?

W przypadku tego rodzaju testów nie obchodzi Cię widoczność, interfejsy itp., Zależy Ci tylko na tym, aby kod działał. Więc tak, przetestowałbyś prywatne i chronione metody, gdybyś uważał, że trzeba je przetestować, aby odpowiedzieć Tak na pytanie.

Podejście (2) Zapobieganie regresji zachowania:

Kiedy już masz działający kod, musisz mieć mechanizm, który chroni go przed przyszłymi uszkodzeniami. Gdyby nikt nigdy więcej nie dotykał twojego źródła i konfiguracji, nie potrzebujesz tego, ale w większości przypadków ty lub inni będziecie dotykać źródła i konfiguracji twojego oprogramowania. To wewnętrzne majsterkowanie jest wysoce prawdopodobne, że złamie twój działający kod.

Mechanizmy istnieją już w większości języków jako sposób ochrony przed tymi uszkodzeniami. Funkcje widoczności to jeden mechanizm. Prywatna metoda jest izolowana i ukryta. Hermetyzacja to kolejny mechanizm, w którym dokonuje się podziału rzeczy, tak aby zmiana innych przedziałów nie wpływała na innych.

Ogólny mechanizm tego nazywa się: kodowanie do granicy. Tworząc granice między częściami kodu, chronisz wszystko wewnątrz granicy przed rzeczami znajdującymi się poza nią. Granice stają się punktem interakcji i umową, poprzez którą rzeczy oddziałują.

Oznacza to, że zmiany granicy, albo przez złamanie jej interfejsu, albo przez złamanie jej oczekiwanego zachowania, mogą uszkodzić i prawdopodobnie złamać inne granice, na których polegały. Dlatego dobrym pomysłem jest przeprowadzenie testu jednostkowego, który jest ukierunkowany na te granice i zapewnia, że ​​nie zmieniają się one pod względem semantycznym i zachowania.

To jest twój typowy test jednostkowy, o którym większość mówi o TDD lub BDD. Chodzi o to, aby granice utwardzały się i chroniły przed zmianami. Nie chcesz testować w tym celu metod prywatnych, ponieważ metoda prywatna nie jest granicą. Metody chronione są ograniczoną granicą i chroniłbym je. Nie są wystawieni na działanie świata, ale nadal są wystawieni na działanie innych przedziałów lub „Jednostek”.

Co z tym zrobić?

Jak widzieliśmy, istnieje dobry powód do testowania jednostkowego metod publicznych i chronionych, aby zapewnić, że nasze interfejsy się nie zmieniają. Jest też dobry powód, aby przetestować metody prywatne, aby potwierdzić, że nasza implementacja działa. Więc czy powinniśmy przetestować je wszystkie?

Tak i nie.

po pierwsze : Przetestuj wszystkie metody, które Twoim zdaniem wymagają ostatecznego dowodu, że działa w większości przypadków, aby mieć pewność, że kod działa, niezależnie od widoczności. Następnie wyłącz te testy. Zrobili tam pracę.

W końcu : pisz testy dla swoich granic. Miej test jednostkowy dla każdego punktu, który będzie używany przez inne jednostki twojego systemu. Upewnij się, że ten test potwierdza kontrakt semantyczny, nazwę metody, liczbę argumentów itp. A także upewnij się, że test potwierdza dostępne zachowanie jednostki. Twój test powinien zademonstrować, jak korzystać z urządzenia i co może zrobić. Pozostaw te testy włączone, aby były uruchamiane przy każdym wypychaniu kodu.

UWAGA: Przyczyną wyłączenia pierwszego zestawu testów jest umożliwienie wykonania prac refaktoryzacji. Test aktywny to sprzężenie kodu. Zapobiega przyszłej modyfikacji testowanego kodu. Chcesz tego tylko dla swoich interfejsów i umów interakcji.

Didier A.
źródło
1
Sprawiasz, że brzmi to tak, jakbyś nie testował jawnie metod prywatnych w izolacji, nie są one objęte Twoimi testami i nie możesz ufać, że zadziałają. Twierdzę, że jest to po prostu błędne. Metoda prywatna (lub dowolna ścieżka w niej zawarta), której nie można przetestować za pomocą metody publicznej, jest martwym kodem i powinna zostać usunięta. Celem TDD jest uzyskanie pełnego pokrycia, testując tylko metody publiczne, ponieważ piszesz 0 LoC, które nie istnieje, aby przejść test. Testowanie izolowanej metody prywatnej służy TYLKO do utrudniania refaktoryzacji, co jest przeciwieństwem (jednego z) celów TDD.
sara
@kai Wyraźnie stwierdzam, że nie powinieneś mieć automatycznych testów dla metod prywatnych, ale czasami warto mieć izolowane testy, które pomogą ci we wdrożeniu. Te testy nie powinny być częścią twojego zestawu testów lub powinny zostać wyłączone z tego samego powodu, o którym wspomniałeś: refaktoryzacja. Do Twojego własnego poziomu pewności należy decyzja, kiedy wolisz mieć zautomatyzowany test do implementacji metody prywatnej, czy nie. Może nie przeczytałeś do końca mojej odpowiedzi?
Didier A.
twierdzisz, że „istnieje również dobry powód, aby testować metody prywatne, aby potwierdzić, że nasza implementacja działa”. Nie widzę do tego podstaw w poście. nie ma niczego, co test metody prywatnej mógłby powiedzieć o działającej implementacji, czego nie mógłby powiedzieć test metody publicznej. Metoda prywatna albo działa, albo nie. Jeśli to nie zadziała, sprawi, że test jednej lub więcej metod publicznych zakończy się niepowodzeniem lub kod jest martwy i / lub nieprzetestowany.
sara
@kai Wspomniałeś: „albo jest martwy i / lub nieprzetestowany kod”. Mówię o nieprzetestowanym kodzie. Metoda prywatna może ukryć wiele błędów, do których przypadki skrajne nie są ćwiczone z metod publicznych. Wyobraź sobie wyłączenie o jeden błąd. Czasami niezmienniki metod publicznych sprawiają, że taki przypadek nigdy się nie wydarzy. W takim przypadku uważam, że metoda prywatna nadal zawiera błędy i ma wadliwą implementację, ale jej integracja zapobiega wykryciu i złapaniu błędu. W takim przypadku możesz potrzebować kilku testów, aby wypróbować przypadki skrajne, aby mieć pewność, że twoja metoda jest wolna od błędów.
Didier A.
@kai Ale zrozum, że te testy, o których mówię, nie są twoim zestawem testów, to nie jest TDD. Mówię, że niektóre metody prywatne są łatwiejsze do wdrożenia, jeśli można szybko przeprowadzić testy przeciwko nim. W językach z REPL nie potrzebujesz tego tak bardzo. Możesz spróbować przejść przez metodę w swojej głowie, ale ja zalecam, aby zamiast tego komputer przeprowadzał testy tylko dla trudnych do zaimplementowania prywatnych metod. Sugeruję późniejsze usunięcie testów lub pozostawienie ich wyłączonych lub we własnym specjalnym miejscu, które nie jest uruchamiane w twojej kompilacji CI.
Didier A.
4

Nie, nie powinieneś testować prywatnych metod (jak byś nie używał czegoś okropnego jak refleksja). W przypadku metod chronionych jest nieco mniej oczywiste w C #, że można sprawić, by elementy chronione były wewnętrzne i myślę, że można to zrobić, aby przetestować klasy pochodne, które implementują całą swoją funkcjonalność za pomocą metod wzorca szablonu.

Ale ogólnie, jeśli myślisz, że twoje metody publiczne robią za dużo, to czas na refaktoryzację twoich klas na bardziej atomowe klasy, a następnie przetestowanie tych klas.

satnhak
źródło
2

Ja również zgadzam się z odpowiedzią @ kwbeam dotyczącą nie testowania metod prywatnych. Jednak ważna kwestia, którą chciałbym podkreślić - metody chronione SĄ częścią eksportowanego interfejsu API klasy i dlatego MUSZĄ zostać przetestowane.

Metody chronione mogą nie być publicznie dostępne, ale z pewnością zapewniasz sposób, aby podklasy ich używały / zastępowały. Coś spoza klasy może uzyskać do nich dostęp, dlatego musisz upewnić się, że ci chronieni członkowie zachowują się w oczekiwany sposób. Więc nie testuj metod prywatnych, ale testuj metody publiczne i chronione.

Jeśli uważasz, że masz prywatną metodę, która zawiera logikę krytyczną, spróbuję wyodrębnić ją do oddzielnego obiektu, wyodrębnić i zapewnić sposób przetestowania jego zachowania.

Mam nadzieję, że to pomoże!

codematix
źródło
2

Jeśli zależy Ci na wysokim pokryciu kodu (sugeruję, że powinieneś), powinieneś przetestować wszystkie metody, niezależnie od tego, czy są prywatne czy chronione.

Protected to rodzaj innego punktu do dyskusji, ale podsumowując, w ogóle nie powinno go tam być. Albo przerywa hermetyzację we wdrożonym kodzie, albo zmusza cię do dziedziczenia z tej klasy, aby ją przetestować, nawet czasami nie musisz dziedziczyć.

Samo ukrycie metody klientowi (uczynienie go prywatną) nie daje mu uprawnienia do tego, aby nie podlegać audytowi. Dlatego można je testować metodami publicznymi, jak wspomniano wcześniej.

Teoman shipahi
źródło
1

Zgadzam się ze wszystkimi: odpowiedź na twoje pytanie brzmi „nie”.

Rzeczywiście, masz całkowitą rację ze swoim podejściem i przemyśleniami, zwłaszcza dotyczącymi pokrycia kodu.

Dodam też, że pytanie (i odpowiedź „nie”) dotyczy również metod publicznych, które możesz wprowadzić na zajęcia.

  • Jeśli dodasz metody (publiczne / chronione lub prywatne), ponieważ kończą się niepowodzeniem, oznacza to, że osiągnąłeś mniej więcej cel TDD.
  • Jeśli dodasz metody (publiczne / chronione lub prywatne), ponieważ po prostu zdecydujesz się na to, naruszając TDD, wtedy pokrycie kodu powinno je wychwycić i powinieneś być w stanie ulepszyć swój proces.

Również dla C ++ (i powinienem myśleć tylko o C ++) implementuję interfejsy używając tylko prywatnych metod, aby wskazać, że klasa powinna być używana tylko przez interfejs, który implementuje. Uniemożliwia mi to błędne wywoływanie nowych metod dodanych do mojej implementacji z moich testów

quamrana
źródło
0

Dobry projekt oznacza podzielenie aplikacji na wiele testowalnych jednostek. Po wykonaniu tej czynności niektóre jednostki są narażone na publiczny interfejs API, ale inne mogą nie być. Ponadto punkty interakcji między eksponowanymi jednostkami a tymi „wewnętrznymi” jednostkami również nie są częścią publicznego API.

Myślę, że gdy już będziemy mieli identyfikowalną jednostkę, testy jednostkowe przyniosą korzyści, niezależnie od tego, czy zostaną ujawnione za pośrednictwem publicznego interfejsu API, czy nie.

Audrius Meskauskas
źródło