2012-11-02 18 views
15

Właśnie zaczęliśmy opracowywać aplikację internetową z AngularJS i mamy problemy z jej testowaniem, abyśmy mogli skorzystać z porady.

Generalnie istnieją następujące komponenty do testu:

  1. Web API
  2. kątowe Kontrolery
  3. kątowe ułożenie
  4. renderowania HTML i kątowe wiązanie Kontrolery do elementów HTML

Jak można to wszystko przetestować przy minimalnym wysiłku, a jeśli to możliwe, nie zachodzić na siebie?

Dla każdej aplikacji opartej na danych baz danych pełne testy integracji (tj. Z serwerem na żywo, połączonym z bazą danych zawierającą dane) byłyby szczególnie kłopotliwe, ponieważ musiałby istnieć proces generujący wystarczające dane dla wszystkich testów i resetów DB i testy musiałyby być ostrożne, aby nie modyfikować danych nawzajem. (jeśli czegoś tu nie ma proszę daj mi znać)

Biorąc pod uwagę powyższy punkt, zakładam, że najlepiej jest odciąć połączenie między serwerem a klientem i uruchomić testy kątowe przy użyciu wyłącznie próbnych danych.

Zakładam również, że jeśli test E2E zajmie się wszystkimi możliwymi scenariuszami, to kontrolery testujące jednostki są nadmiarowe, ponieważ ich wartości są powiązane z modelem (i dlatego testowałyby wszystkie z 2, 3 i 4 powyżej). Testowanie jednostek byłoby pomocne tylko w bardzo złożonych kontrolerach lub testowaniu usług i dyrektyw.

Nie znaleźliśmy jednak żadnych informacji o tym, jak kpić z $httpBackend na podstawie testu, tak jak w testach jednostkowych, używając expect*(). Angularne dokumenty wydają się sugerować używanie when*() plus sporadycznie passthrough(), gdy jest to konieczne.

Ale to stwarza wyżej wspomniany problem tworzenia danych testowych dla wszystkich scenariuszy i prawdopodobnie trzeba będzie zresetować DB w pamięci przed każdym testem, aby upewnić się, że testy nie zostaną zmienione. Ponadto tracisz bezpieczeństwo korzystania z usługi $httpBackEnd.expect*(), która sprawdza, czy nie ma żadnych brakujących lub nadmiarowych połączeń z serwerem - Sugerowałoby to, że wymagałoby to również kontrolerów testujących jednostki, aby to sprawdzić.

Czy ktoś może przedstawić szczegółową strategię testowania aplikacji AngularJS, która dotyczy testowania powyższych 4 komponentów, a także problemów opisanych powyżej?

+0

Nadal myślę o różnych pomysłach w mojej głowie. Myślę, że najważniejszą rzeczą do zrobienia jest przetestowanie pełnej aplikacji na prawdziwej bazie danych. Jest to również najtrudniejsze. Używanie scenariusza kątowego w tym przypadku wydaje się nieco błędne, ponieważ wtedy zamykasz się na Angulara dla wszystkich swoich testów. Coś w rodzaju Selenium WebDriver wydaje się lepsze, ale jest to również trudniejsze do skonfigurowania. Wrócę do tego, jeśli znajdę ostateczną strategię. – iwein

+0

Absolutnie. Testowanie wartości jest oparte na prawdziwej bazie danych. +1 za wybranie czegoś spoza ekosystemu Angular, chociaż nie ma naturalnych predyspozycji do wprowadzenia Selenium. Możesz wybrać dowolną implementację selenu, taką jak Python, C# lub Java. – fatuhoku

Odpowiedz

6
  1. Nie jestem pewien - Ponieważ kątowa aplikacja jest teoretycznie oddzielona od zaplecza, nie ma szczególnego powodu, że kątowe testy i badania backend muszą zostać zmieszane. Przetestowałbym je osobno, z każdym zestawem testów, zakładającym, że drugi komponent działa dobrze. (Dlatego podczas testowania kątowego zakłada się, że serwer będzie działał zgodnie z oczekiwaniami).

  2. Jednostkowe testy - zapewniają większą głębię niż testy E2E. Łatwiej jest zweryfikować konkretne warunki, przed którymi stanie kod. Łatwo też wyśmiewać wszystkie zależności, jeśli jest to konieczne, i testować tylko ten komponent, którego dotyczą testy jednostkowe. Testy jednostkowe nie dotyczą samej funkcjonalności interfejsu lub prawidłowości danych, lecz logiki biznesowej. aplikacji jest poprawna.

  3. (i 4) Testy E2E - mniej szczegółowości, koncentrując się na upewnieniu się, że interfejs wygląda zgodnie z oczekiwaniami z perspektywy użytkownika końcowego. Masz rację, że testowanie w oparciu o bieżącą bazę danych jest kłopotliwe (chociaż niektórzy ludzie cieszą się bezpieczeństwem zapewnionym przez kompleksowy test integracji), więc powinieneś użyć numeru $httpBackend, aby wyłudzić serwer.

Powiązane problemy