Czy naprawdę musisz najpierw wykonać test BDD / TDD?

11

Mimo że nie brałem udziału w projekcie TDD ani BDD, lub w niektórych z nich mówi się, że robią TDD, ale są dość dalekie, to są rzeczy, o których myślę i naprawdę staram się czytać jak najwięcej o.

Powrót do pytania Kiedy robisz BDD, powinieneś najpierw napisać swój „test” i sprawić, że się nie powiedzie, prawda? A następnie zaimplementuj tę funkcję lub jak ją nazwiesz. Ale jeśli podejmiesz to do końca, czy nie może to być jakiś rodzaj odgórnego rozwoju? Patrzysz na swój interfejs i mówi: „Chciałbym mieć tę funkcję / zachowanie tutaj”. Następnie naprawiasz interfejs użytkownika, aby zaimplementować tę funkcję oraz kod obsługujący interfejs użytkownika. W tym momencie nie zaimplementowałeś żadnej logiki biznesowej ani logiki dostępu do danych, właśnie zaimplementowałeś swoje zachowanie. Do czego dążę, zamiast pisać test jako pierwszy, najpierw piszesz kod interfejsu użytkownika. W niektórych przypadkach powinno to skutkować tym samym kodem dostępu do danych i warstwy biznesowej, ponieważ używasz kodu interfejsu użytkownika, aby określić, co Twoja firma musi obsługiwać.

Oczywiście powinieneś uzupełnić to testami, które służą do upewnienia się, że funkcja działa tak, jak powinna w funkcji.

jakieś pomysły?

unit-testing tdd

— Tomas Jansson
źródło

Testy w ramach TDD są testami jednostkowymi , które napędzają moduł bezpośrednio, tak jakby odbywał się on osobno main. W swoim odgórnym komentarzu mówisz o testach funkcjonalnych, które wykonują cały program za jednym razem main.

— Macneil

@Macneil: Nie mówię o teście funkcjonalnym, który testuje cały program, nawet myślałem, że wdrażasz / projektujesz program odgórnie, nadal powinieneś wdrożyć test jednostkowy dla całego swojego kodu publicznego. To, że robisz to z góry na dół, nie oznacza, że nie możesz tworzyć różnych warstw abstrakcyjnych, więc możesz samodzielnie izolować wszystkie warstwy.

— Tomas Jansson

1

@Macneil: Jest to powszechne nieporozumienie. Testy TDD nie są testami jednostkowymi . Funkcje testowe TDD , które nie mają ustawionej skali.

— Steven A. Lowe

2

Ale istnieje ustalona skala: test musi zostać wykonany szybko w TDD. Muszą wystąpić testy, które również są poza zakresem TDD. Ogólnie rzecz biorąc, TDD to plan rozwoju, a nie plan testów.

— Macneil

@Macneil: „szybko” to termin względny. Pakiet testowy w moim ostatnim projekcie jest wykonywany za około 30 minut. Zastępuje 8 godzin testów ręcznych. To wystarczy „szybko”!

— Steven A. Lowe

8

Mówisz o BDD z wysokiego poziomu testowania interfejsu użytkownika. Testowanie jest nieco bardziej puszyste na tym poziomie niż niżej w kodzie JavaScript / serwera.

Kilka książek, które przeczytałem na temat TDD, mówi, że powinieneś pisać kod tak, jakby istniały systemy bazowe, i po prostu napisać tyle, aby zdać test. Możesz napisać kody pośredniczące na serwerze, aby pomyślnie przejść testy behawioralne interfejsu użytkownika. Następnie zaczynasz od tego krótkiego odcinka i piszesz testy jednostkowe dla kodu po stronie serwera i przechodzisz do pełnej implementacji.

Często koduję tak, jakby istniały podstawowe warstwy, aby przejść test wysokiego poziomu, wydaje się, że zejść do króliczej dziury i wyodrębnić wiele innych klas, aby spełnić test wysokiego poziomu, a następnie napisać testy dla tych niższych poziomów. Jak już wiesz, pomaga utrzymać koncentrację, zaczynając od testów na wyższym poziomie.

Jak wie doświadczony programista, istnieje wiele warstw do tworzenia oprogramowania. Zwykle pracuję niżej niż interfejs użytkownika i myślę o danych lub zachowaniu, którego potrzebuje mój interfejs użytkownika z serwera i zaczynam od tego (być może dlatego, że w dzisiejszych czasach nie pracuję dużo).

Jeśli jestem naprawdę szczery, wyodrębnienie klasy z podstawowych warstw oznacza, że najpierw nie przeprowadzam testu, ale ... w ciągu kilku minut, a czasem godzin przeprowadzę test tego kodu. To nadal wydaje mi się korzystne, ponieważ pomagam zobaczyć, gdzie możesz potrzebować dostarczyć zależności do klasy i przestrzegać zasady pojedynczej odpowiedzialności - jeśli trudno jest przetestować, robisz za dużo w jednym miejscu itp.

— Greg K.
źródło

Myślę, że masz rację. To dotarło do mnie, kiedy tego lata wypróbowałem ruby na szynach, tam są jakieś testy bdd, które sterują interfejsem użytkownika, który później napędza implementację podstawowych klas.

— Tomas Jansson,

17

Tak! W przeciwnym razie otrzymujesz testy rozwojowe .

Realistycznie rzecz biorąc, istnieją problemy, do których trudno jest podejść przy użyciu „czystego” TDD. Możesz być bardziej produktywny, pisząc trochę odkrytego kodu produkcyjnego i pokrywając go testami później (i ucząc się, jak podejść do podobnych problemów z TDD w przyszłości). Spójrz na tę technikę , którą autor nazwał TDD płukaniem i powtarzaniem z braku lepszego terminu.

— azheglov
źródło

3

Pierwsza linia jest niesamowita.

— EpsilonVector,

W porównaniu z TDD to prawda, ale robienie rzeczy odgórnie powinno dobrze pasować do BDD, prawda? Patrzę na GUI i określam zachowanie, które chcę, na pewno nie piszę „testu zachowania” od razu, ale określiłem zachowanie w interfejsie użytkownika, zanim go zaimplementowałem.

— Tomas Jansson

15

Jeśli najpierw nie napiszesz testów, nie napędzasz rozwoju przez swoje testy. Ergo, nie zajmujesz się programowaniem opartym na testach!

— Frank Shearar
źródło

Szczerze mówiąc, czy nie jest pytanie, czy podczas wykonywania BDD (nie TDD), czy powinniśmy najpierw napisać test?

— bytedev

Zachęcamy do zastąpienia „testu” słowem „zachowanie”. Nie widziałem niczego, co by mnie przekonało, że w istocie istnieje duża różnica między TDD a BDD. Może się skupić. Ale podstawowa idea? Nie tak bardzo.

— Frank Shearar

Nie zgadzaj się z faktem, że nie zajmujesz się programowaniem testowym. Nie robisz tego zgodnie z definicją kluczowanego terminu, ale dopóki opracowujesz testy dla swojego kodu, Twój kod jest zdecydowanie napędzany przez testy, niezależnie od tego, kiedy je piszesz.

— alternatywnie

TDD oznacza w szczególności pisanie testów przed kodem. Jeśli ci się nie podoba, weź to z Kentem Beckiem, który wymyślił ten termin. Pisanie testów po kodzie może w pewnym stopniu prowadzić kod , ale nadal możesz oszukać się, że prowadzisz swój projekt kodu przez testy, gdy tak nie jest. I trudniej jest napisać te testy, ponieważ często trzeba zmienić nieprzetestowany kod . Widziałem to zbyt często, aby wspomnieć.

— Frank Shearar

@FrankShearar Przyznałem, że nie jest to TDD zgodnie z tym, co powiedział Kent Beck, ale szczerze mówiąc, nie dbam o to, co powiedziała jakaś przypadkowa osoba. Jest całkowicie możliwe przeprowadzanie projektu kodu poprzez testy bez uprzedniego pisania testów.

— alternatywny

4

Jeśli chcesz pracować w ten sposób, idź do niego. Ale to nie jest rozwój oparty na testach.

— Don Roby
źródło

3

To, co opisujesz, brzmi bardzo podobnie do podejścia z przodu . Niestety, projekt z przodu jest satyrycznym ciosem Alexa Papadimoulisa w zwinne metody.

— użytkownik 281377
źródło

Zastanawiałem się, czy znasz jakieś artykuły, które walczą w FAD, obalając satyryczne pchnięcie?

— CL22,

3

Osobiście uważam, że bardzo ważne jest, aby pomyśleć o testowaniu na etapie projektowania. Naprawdę świetnie jest mieć działającą implementację, ale jedynym sposobem na upewnienie się, że masz działający produkt, jest przetestowanie go kawałek po kawałku. Sposobem na pokrycie tego jest połączenie testów jednostkowych i wykwalifikowanego zespołu ds. Kontroli jakości współpracującego z partnerami.

Teraz, jak zainstalujesz tę dyscyplinę w swoim zespole, zależy od ciebie. TDD jest jedną z takich strategii - i taką, która ma swoje miejsce i istnieje wiele innych odmian. Jednak TDD nie nadaje się szczególnie do opracowywania układu interfejsu użytkownika.

— Michael Shaw
źródło