Czy mogę testować tylko publiczne interfejsy w BDD? (w ogóle, a konkretnie w Rubim)

Question

Przeczytam (nadal beta) rspec book by the prag progs, ponieważ interesują mnie testy behawioralne obiektów. Z tego, co udało mi się zebrać do tej pory (uwaga: po zaledwie przeczytaniu przez 30 minut), podstawową ideą jest to, że chcę, aby mój obiekt zachowywał się zgodnie z oczekiwaniami "zewnętrznie", tj. W jego wynikach iw odniesieniu do innych obiektów.

Czy to prawda, że ​​powinienem po prostu być czarną skrzynką testującą mój obiekt w celu zapewnienia właściwego wyjścia/interakcji z innymi obiektami?

To może być kompletnie błędne, ale biorąc pod uwagę, jak mój obiekt zachowuje się w systemie, wydaje się, że jest to ideologia, którą należałoby przyjąć. Jeśli tak, to jak skupiamy się na implementacji obiektu? Jak mogę przetestować, że moja prywatna metoda robi to, co chcę robić dla wszystkich typów danych wejściowych?

Przypuszczam, że to pytanie może być ważne dla wszystkich rodzajów testów? Nadal jestem całkiem nowy w TDD i BDD.

Answer 1

Jeśli chcesz lepiej zrozumieć BDD, spróbuj o tym myśleć bez użycia słowa "test".

Zamiast pisać test, napiszesz przykład, jak możesz używać swojej klasy (i nie możesz jej używać poza publicznymi metodami). Pokażycie, dlaczego klasa jest wartościowa dla innych klas. Określasz zakres obowiązków swojej klasy, pokazując (poprzez drwiny), jakie obowiązki są delegowane gdzie indziej.

Jednocześnie możesz zapytać, czy obowiązki są odpowiednie, i dostosować metody na twojej klasie tak, aby były jak najbardziej intuicyjnie użyteczne. Szukasz kodu, który jest łatwy do zrozumienia i używania, a nie kodu, który jest łatwy do napisania.

Jeśli potrafisz myśleć w kategoriach przykładów i dostarczania wartości poprzez zachowanie, utworzysz kod, który będzie łatwy w użyciu, wraz z przykładami i opisami, które inni mogą śledzić. Uczynisz swój kod bezpiecznym i łatwym do zmiany. Jeśli myślisz o testowaniu, przyłapiesz go, aby nikt nie mógł go złamać. Będzie ci ciężko się zmienić.

Jeśli jest wystarczająco złożony, że istnieją wewnętrzne metody, które naprawdę chcesz przetestować osobno, podziel je na inną klasę, a następnie pokaż, dlaczego ta klasa jest wartościowa i co robi dla klasy, która z niej korzysta.

Mam nadzieję, że to pomoże!

Answer 2

Tak, skup się na odkrytej funkcjonalności klasy. Prywatne metody są tylko częścią publicznej funkcji, którą przetestujesz. Ten punkt jest nieco kontrowersyjny, ale moim zdaniem powinno wystarczyć przetestowanie publicznej funkcjonalności klasy (wszystko inne narusza również zasadę OOP).

Answer 3

Myślę, że są tu dwie sprawy.

Jednym z nich jest to, że z perspektywy BDD zwykle testujesz na wyższym poziomie niż z perspektywy TDD. Tak więc testy BDD zapewnią większą funkcjonalność niż testy TDD i zawsze powinny być testami "czarnej skrzynki".

Po drugie, jeśli czujesz potrzebę, aby przetestować metod prywatnych, nawet na poziomie testów jednostkowych, które mogą być zapach kod, że kod jest naruszenie Single Responsibilty Principle i powinny być refactored tak, że metody dbasz o można przetestować jako publiczne metody innej klasy. Michael Feathers wygłosił interesującą rozmowę na ten temat, zatytułowaną "The Deep Synergy Between Testability and Good Design".