Czy warto używać TDD do biblioteki/kodu API i BDD jako testów integracyjnych?

Question

Jestem kompletnym początkującym dla BDD i chciałbym zrozumieć, gdzie to ma miejsce w cyklu rozwojowym. W podejściach TDD piszemy testy jednostkowe zwykle dla bibliotek lub apis, szydzimy z obiektów i to było wspaniałe, ponieważ mogło nawet napędzać nasz projekt. Testy te zostaną napisane przed właściwym kodem, który jest miły.

Rozumiem, że BDD to raczej testowanie specyfikacji/scenariuszy i widzę, że jest to idealne dopasowanie do testowania wymagań biznesowych w stosunku do rzeczywistego kodu. Ale jaka jest najlepsza praktyka pisania tych testów? Czy wciąż piszemy testy indywidualne (jak w TDD) wyśmiewając zależności i pisząc testy jednostkowe dla każdej rzeczy, która może pójść nie tak? Następnie napisz nasze testy bdd? Czy najpierw piszemy testy bdd? Czy piszemy tylko testy bdd, nawet przeciwko poszczególnym komponentom?

Używam .NET i zazwyczaj piszę aplikacje asp.net mvc, ale jest to raczej kwestia teoretyczna i niezależna od podstawowego języka programowania.

Wielkie dzięki.

Answer 1

Nie znam właściwej drogi, ale to jest moje doświadczenie. Po przeanalizowaniu dokumentu specyfikacji próbuję wyodrębnić tyle różnych "historii" i opisać je za pomocą plików historii BDD. Jak już wiesz, każde zdanie powinno zaczynać się od jednego z trzech słów kluczowych: podanych, gdy i , a następnie.

Po przetłumaczeniu całej specyfikacji na opowieści testowe BDD piszę klasę, która implementuje kroki, tj. Wykonuje każde ze zdań używanych w opowiadaniach.

Następnym krokiem jest napisanie implementacji, która zostanie wywołana metodami, które wykonują zdania skryptu, ustawiając stan początkowy (dany), przejścia stanu (kiedy) i sprawdzając stan docelowy aplikacji (wtedy).

Ilekroć potrzebuję wdrożenia rzeczywistej metody klasy, używam TDD do dokładnego testowania w izolacji.

Oczywiście, aby uruchomić część testową kodu, który nie został jeszcze zaimplementowany, można tymczasowo wyśmiać.

Answer 2

Można go używać podobnie jak TDD, testowanie jednostkowe lub w inny sposób. Różnica będzie pochodzić z testowania "Zachowań biznesowych". Spec przepływu i cech jest jedna opcja, składnia testów jednostkowych będzie wyglądał jak ten

[Given(@"a user exists with username ""(.*)"" and password ""(.*)""")] 
public void GivenAUserExistsWithUsernameAdminAndPasswordPassword(string userName, string password) { 

} 

[Then(@"that user should be able to login using ""(.*)"" and ""(.*)""")] 
public void ThenThatUserShouldBeAbleToLoginUsingAdminAndPassword(string userName, string password) { 
     Assert.IsTrue(_authService.IsValidLogin(userName, password)); 
    } 

Answer 3

BDD jest zbiorem wzorów wokół opisującego i budowlanej modele zachowań systemu (i na wyższym poziomie, projekt wizja), które mogą nam pomóc w prowadzeniu rozmów na temat tego zachowania na różnych poziomach szczegółowości.

Używamy wzorów konwersacyjnych, takich jak "Biorąc pod uwagę kontekst, kiedy to wydarzenie ma nastąpić, a następnie wynik powinien się pojawić", i zachęcić do pytań typu: "Czy to zawsze? Czy są jakieś inne konteksty, których nam brakuje?"

Możemy to zrobić na poziomie jednostki, scenariusza lub nawet w przestrzeni analitycznej.

Mam tendencję do pracy od najwyższego poziomu do wewnątrz. Here's an article I wrote, która opisuje to, co wygląda, od wizji projektu do testów jednostkowych.

Pierwszym bitem, który zapiszę, będą scenariusze.Here are some scenarios napisane bez żadnych frameworków BDD, po prostu zwykły NUnit, pokazujący, jak można je odczytać w języku angielskim za pomocą języka domeny itp.

Następnie zaczynam od interfejsu użytkownika. Może to być GUI, strona internetowa lub interfejs innego systemu do korzystania z mojego systemu. Gdy to zrobię, będę mógł uzyskać informację, czy podobają się moi użytkownicy. Często koduję dane, itp., Po to, aby uzyskać informacje zwrotne.

Gdy już się z grubsza dowiem, jak będzie wyglądał mój GUI, mogę zacząć tworzyć zachowanie za nim. Zwykle zaczynam od zachowania kontrolera. Będę pisać przykłady na poziomie klasy, które opisują zachowanie i obowiązki klasy. Używam makiet zamiast kolaboracyjnych zajęć, których jeszcze nie napisałem. Jest to odpowiednik TDD, ale zamiast pisać testy, które kodują kod tak, aby nikt go nie zepsuł, piszę przykłady tego, jak możesz użyć mojego kodu, który pokazuje, jak się zachowuje i dlaczego jest cenny, abyś mógł zmienić to bezpiecznie. Używam również Given/When/Then do tego! Ale używam języka bardziej technicznego i nie przejmuję się tym, że jest on czytelny w języku angielskim. Często moje Given/When/Then są tylko w komentarzach. Here's an example of class behaviour z tego samego kodu, co scenariusze, dzięki czemu można zobaczyć, jaka jest różnica.

Mam nadzieję, że to pomoże, i powodzenia z BDD!