Witam!
Dotychczas tworzyłem serwisy, które nie wykorzystywały żadnych frontendowych frameworków MV*. Ostatnio jednak stanąłem przed wyzwaniem napisania aplikacji, która składa się z jsonowego backendu oraz frontendu stworzonego przy użyciu angulara. O ile w przypadku pierwszego typu aplikacji dostępna jest masa przykładów testów i wszystko jest w miarę jasne, o tyle w przypadku drugiego typu sprawa nieco się komplikuje.
Pytania brzmą następująco:
jak najlepiej zaprojektować testy takiej aplikacji? Czy da się “za jednym zamachem” testować backend jak i angularowy frontend czy raczej skazany jestem na użycie osobnego test frameworka pod angulara? Było by świetnie, gdyby dało testować się angulara przy pomocy capybary i feature specs ale niestety jedyny dedykowany do tego gem nie działa.
Większość artykułów dotyczących testowania API (a jest ich dosyć niewiele) sugeruje użycie request specs do testowania kodów odpowiedzi oraz zwracanych danych. Czy nie lepsze by tutaj było użycie np. view specs (do testowania zwracanych danych)? Jeśli tak, to logicznym wydaje mi się testowanie “reszty” przy pomocy controller specs. Był bym bardzo wdzięczny, gdyby ktoś mający do czynienia z takimi aplikacjami na codzień podzielił się ze mną swoim doświadczeniem
Czy rspec oferuje możliwość testowania całych scenariuszy i przypadków użycia aplikacji? Z tego co wiem (a moge się mylić) najbliższe temu są features spec ale wydaje mi się, że służą one bardziej do testowania pojedynczych funkcjonalności a nie całych procesów i scenariuszy. Chciał bym po prostu móc przetestować cały proces użytku aplikacji przez użytkownika. Od rejestracji, przez logowanie i obsługe, aż do wylogowania się (chociaż być może kłóci się to z jakimiś podstawowymi założeniami i “best practices” pisania dobrych testów)
Niedawno miałem ten sam problem. Zacząłem mój pierwszy projekt zbudowany w ten sposób i nagle pojawiło się pytanie: Jak to testować??
Próbowałem w jakiś sposób ogarnąć features testy, ale nie udało mi się tego osiągnąć. Capybara i rzeczy typu fill_in po prostu nie działały. W końcu zrezygnowałem z tego i z próby otestowania całego, jakiegoś większego procesu z perspektywy użytkownika i klikania po przeglądarce.
Wydaje mi się teraz, że podejście do faktycznego otestowania tylko API jest dobre. Na dobrą sprawę mamy dwie oddzielne aplikacje (Rails + Angular) i powinny być one otestowane oddzielnie.
Testy modelowe wiadomo zostają takie same, jeśli używamy serwisów to też w niczym to nie różni się od testów przy standardowym podejściu.
Jedyna różnica to więcej testów kontrolerowych, w których testujemy tak naprawdę jak zachowa się nasza aplikacja i co zwróci, gdy dostaniemy taki lub inny request - a tak naprawdę to chyba wszystko co nas interesuje pisząc API.
PS. Liczę też na wypowiedź kogoś mądrzejszego i wskazanie lepszej drogi
Nie jestem pewien jaki jest powód stosowania takiego gemu - capybara bez żadnych dodatków sobie całkiem nieźle radzi z czekaniem na pojawienie się różnych elementów.
Założeniem view specs jest testowanie logiki widoku, najczęściej używając stubów, więc o ile chcesz przetestować coś więcej niż wygenerowanie odpowiedzi, to view specs są słabe. “controller specs” pozwalają Ci uruchomić kod, który wykonuje się w kontrolerze, ale jest to odizolowane od reszty aplikacji, więc np. nie uruchomią się chociażby rack middlewares.
Request specs wysyłają do aplikacji dane, które normalnie zostałyby wysłane z serwera, więc jest to dużo bliższe wersji, która wykonuje się na produkcji.
Rspec głównie uruchamia kod dla każdego z testów i sprawdza czy wszystkie asercje są prawidłowe, co tam włożysz zależy tylko i wyłącznie od Ciebie.[quote=“dedoel, post:2, topic:8163”]
Próbowałem w jakiś sposób ogarnąć features testy, ale nie udało mi się tego osiągnąć. Capybara i rzeczy typu fill_in po prostu nie działały.
[/quote]
Żeby testować aplikację javascriptową trzeba pod capybarę podpiąć jakiś driver, który jest w stanie testować javascript. Domyślnie jest to rack/test, więc nie ma takiej możliwosci. Poszukaj o capybarze z webdriverem albo np. phantomjs
Co do sedna tematu, to ja polecam testowanie oddzielnie API i oddzielnie aplikacji javascriptowej. Angular używa karma.js i generalnie dość łatwo jest tam pisać testy funkcjonalne i co najważniejsze są one dużo szybsze niż testy, które używają bazy danych. Dla bezpieczeństwa można dodać jakieś testy akceptacyjne, które testują obie aplikacje na raz, ale ja bym zrobił to tylko dla najważniejszych części.
Do testowania api bardzo fajnie nadaje sie jmeter: http://jmeter.apache.org/. Uzywa sie go bardzo latwo, ma duzo opcji, mozna go uruchomic na dowolnym serwerze z java, i mozna tez go uzyc to testowania performance.