2009-05-29 13 views
9

Staram się dowiedzieć, co powinno być wyłączone z testów funkcjonalnych (w moim przypadku, używając Railsów, ale chyba struktura ta jest prawdopodobnie nieistotna).Zamieszanie: pominąć testy funkcjonalne, które obejmują ten sam obszar, co testy jednostkowe?

Mam wrażenie, że nie powinienem zawracać sobie głowy testami funkcjonalnymi na rzeczy, które zostaną przechwycone podczas testów jednostkowych - takich jak sprawdzenie, czy pole nie może mieć zbyt wielu znaków lub że pole może ". t być puste. Jeśli tak, to jakie ewentualności należy zdecydowanie przetestować za pomocą testów funkcjonalnych i/lub jaka jest zasada, aby pozostawiać innych tylko do testowania jednostkowego?

Czy to wrażenie jest niepoprawne na samym początku?

Szukałem na this i this ale nadal jestem w rozterce.

Odpowiedz

7

Test funkcjonalny: Czy robi on rzeczy marketing/usability/klienci podpisani dla? np. jeśli specyfikacja specyfikuje konkretnie, że pole tekstowe ZIP zezwala tylko na prawidłowe kody pocztowe w USA, to prawdopodobnie należy je przetestować w teście funkcjonalnym.

Test jednostek: Czy robi to, co programista oczekuje od? W tych testach powinieneś użyć testu podwójnego testu, aby wyizolować kod z zależności.

Tak, będzie nakładanie się rodzaju.

+0

W przypadku funkcjonałów, czy powinieneś przetestować każdy możliwy przypadek? Wygląda na to, że naprawdę nie możesz niczego usunąć z funkcjonałów. – fig

+0

Nie sądzę, żebyś przetestował każdy przypadek w funkcjonałach, przetestujesz przypadki wyraźnie określone w specyfikacji. Prawdopodobnie będziesz mieć również testy jednostkowe dla tych i, miejmy nadzieję, inne testy jednostkowe dla rzeczy, o których myślałeś, a oni nie. – Robert

+0

Zdecydowanie * nie * jestem ekspertem od testów. Uważaj więc, aby nie skorzystać ze wskazówek, ale przynajmniej sprawdziłbym poprawność działania funkcji wymaganej w specyfikacji. Twój test jednostki może brutalnie przetestować wszystkie możliwe kody pocztowe w USA, ale twój test funkcjonalny może wypróbować 1 niepoprawny i 1 ważny zip. – dss539

3

Ja osobiście "przebiję" się przez funkcjonalność testami funkcjonalnymi i nie martwię się o wszystko, a zamiast tego skupię się na testach jednostkowych.

Przyczyny:

  • testy funkcjonalne są powolne
  • testy funkcjonalne są trudne do napisania i utrzymania
  • testy funkcjonalne mogą tylko złapać dwa dodatkowe przedmioty oprócz swoich testów jednostkowych:
    • GUI bugs
    • niedopasowanie między warstwami

Podsumowując, stwierdziłem, że nie opłaca się pokryć wszystkiego dwa razy.

+0

W swoim podejściu, w jaki sposób wybrać, które rzeczy należy uwzględnić, a które pominąć? Czy jest to przypadek, czy istnieje pewna zasada? – fig

+1

Zasada kciuka obejmuje jeden przypadek użycia z "historii" za pomocą jednego testu integracji. Na przykład, gdybym miał stronę płatności, po prostu przetworzyć udaną płatność, aby sprawdzić, czy integracja została wykonana prawidłowo. Test jednostkowy obejmowałby wszystkie pozostałe przypadki. –