Zwinny sposób: testowanie integracji vs testowanie funkcjonalne czy jedno i drugie? [zamknięte]

Doświadczyliśmy, że solidny zestaw testów selenu naprawdę dobrze podsumowuje to, czego klient oczekuje od jakości. Tak więc, w istocie prowadziliśmy tę dyskusję: jeśli pisanie testów selenium było tak proste, jak pisanie testów jednostkowych, powinniśmy skupić się mniej na testach jednostkowych.

A jeśli gdzieś jest błąd, który nie ma żadnych konsekwencji w aplikacji, to kogo to obchodzi? Ale zawsze są problemy związane z rzeczywistymi zawiłościami; czy jesteś pewien, że Twoje funkcjonalne testy sprawdzają poprawne scenariusze ? Mogą występować zawiłości spowodowane przez inne systemy, które nie są bezpośrednio widoczne w zachowaniu aplikacji.

W rzeczywistości pisanie testów selenium (przy użyciu odpowiedniego języka programowania, nie selenese) robi naprawdę proste i przyjemne, gdy przewiercisz się przez początkowe problemy. Ale nie jesteśmy jeszcze gotowi zrezygnować z testów jednostkowych....

Testy jednostkowe, testy integracyjne i testy funkcjonalne służą różnym celom. Nie należy odrzucać jednego tylko dlatego, że inne działają na wysokim poziomie niezawodności.

Powiedziałbym (i to tylko kwestia opinii), że twoje testy funkcjonalne są twoimi prawdziwymi testami. Czyli te testy, które faktycznie symulują rzeczywiste użycie aplikacji. Z tego powodu nigdy się ich nie pozbywaj, bez względu na wszystko.

Wygląda na to, że masz porządny system. Zatrzymaj wszystko, jeśli nie masz nic do stracenia.

U mojego obecnego klienta nie rozróżniamy testów jednostkowych od testów integracyjnych. Podmioty biznesowe są tak zależne od podstawowej warstwy danych (przy użyciu macierzystego frameworka ORM), że w efekcie mamy niewiele lub nie mamy prawdziwych testów jednostkowych.

Serwer kompilacji jest skonfigurowany z ciągłą integracją (CI) w teamie Build i aby zapobiec zbytnio powolnym testom (uruchomienie pełnego zestawu testów na serwerze zajmuje ponad godzinę), rozdzieliliśmy testy na "powolne" testy to jest uruchamiane dwa razy dziennie i" szybkie " testy, które są uruchamiane w ramach ciągłej integracji. Ustawiając atrybut na metodzie testowej, build-server może odróżnić te dwa elementy.

Ogólnie rzecz biorąc," powolne " testy to wszystko, co wymaga dostępu do danych, korzystania z usług internetowych lub podobnych. Według wspólnej konwencji byłyby one uznawane za testy integracyjne lub testy funkcjonalne. Przykłady to: CRUD-tests, business validation rule tests, które wymagają zestawu obiektów do pracy z, itd.

"szybkie" testy są bardziej jak testy jednostkowe, gdzie można rozsądnie wyizolować stan i zachowanie pojedynczego obiektu do testu.

Każdy test, który przebiega w dziesiątych częściach sekundy lub mniej, uznałbym za "szybki". Wszystko inne jest powolne i prawdopodobnie nie powinno być uruchamiane jako część CI.

Zgadzam się, że nie powinieneś się zbytnio przejmować "smakiem" testu, którego używasz w ramach rozwoju (wyrażanie kryteriów akceptacji jako testów jest oczywiście wyjątkiem). Indywidualne programista powinien wykorzystać swoją ocenę, decydując, jaki rodzaj testów najlepiej pasuje do jego kodu. Naleganie na testy jednostkowe dla podmiotu gospodarczego może nie ujawnić błędów CRUD-test będzie i tak dalej...

Porównuję testowanie jednostkowe jako upewnianie się, że słowa w akapicie są napisane poprawnie. Testowanie funkcjonalne jest jak upewnienie się, że akapit ma sens i dobrze płynie w dokumencie, w którym żyje.

Staram się nie oddzielić różnych smaków testów w TDD. Dla mnie TDD to Test-Driven Development, a nie Unit-Test-Driven Development. Moja praktyka TDD łączy testy jednostkowe, integracyjne, funkcjonalne i akceptacyjne. Powoduje to, że niektóre komponenty są objęte pewnymi rodzajami testów, a inne komponenty są objęte innymi rodzajami testów w bardzo pragmatyczny sposób.

Zadałem pytanie o znaczenie tej praktyki i krótka odpowiedź brzmiała że w praktyce rozdzielenie jest między szybkie / proste testy uruchamiane automatycznie przy każdej kompilacji i powolne / złożone testy uruchamiane rzadziej.

Moja firma wykonuje testy funkcjonalne, ale nie testy jednostkowe lub integracyjne. Staram się zachęcić do ich przyjęcia, widzę je jako zachęcanie do lepszego projektowania i szybsze wskazanie, że wszystko jest dobrze. Czy potrzebujesz testów jednostkowych, jeśli wykonujesz testy funkcjonalne?

Bardzo podoba mi się koncepcja "testu Oszczędzania twarzy" Gojko Adzica jako sposobu na określenie tego, co testujesz za pomocą interfejsu użytkownika: http://gojko.net/2007/09/25/effective-user-interface-testing/

Powinieneś zrobić je wszystkie, ponieważ testy jednostkowe, integracyjne i funkcjonalne służą różnym celom.
Należy do mnie ważny punkt jest to, że sposób pisania testu jest bardzo ważny i TDD nie jest wystarczająca, BDD (behavior driven development) dać dobre podejście...