Prawidłowe (i użyteczne) testy w RSpecu

Jak na razie to moje testy opierały się na tym co dowiedziałem się z railstutorial.org i widzę, że to trochę mało.

Analizując jakieś cudze projekty zaczynam widzieć, że testów pisać praktycznie nie umiem, bo jeszcze o ile potrafię je zrozumieć, to sam bym czegoś takiego nie był w stanie napisać :smiley:

Z jednej strony chodzi o sam warsztat i poznanie RSpeca, ale bardziej chodzi o filozofię TDD/BDD (śrendnio to rozróżniam jeszcze, ale RSpec to BDD)
Czyli jak prawidłowo testować w duchu zarówno RSpeca i Railsów. Co należy testować itp. Moglibyście podrzucić jakieś proste (przystępne) materiały, głównie na temat tego co i jak testować, gdy np. pisze się jakąś appke całkowicie od zera i trzeba po kolei samodzielnie dopisywać testy.

Chciałbym pisać tak, żeby te testy rzeczywiście były przydatne i pomocne, a nie były tylko ozdobą :smiley:

Testować trzeba to, co jest ważne dla działania Twojej aplikacji. Albo: to gdzie pojawienie się regresji będzie zbyt kosztowne żeby sobie na to pozwolić.
Co konkretnie to oznacza (jaki fragment, a może całość, a może pojedyncza klasa, a może jakiś konkretny wycinek funkcjonalności przykryty testem akceptacyjnym) to już musisz sam stwierdzić.

Podstawowym pytaniem jakie powinno ci towarzyszyć przy pisaniu testu to “kiedy ten test się wywali?”. Jeśli nie potrafisz na to pytanie odpowiedzieć, to znaczy że test jest niepotrzebny.

W kolejnym etapie warto każdego buga najpierw odtworzyć w formie wykładającego się testu a potem dopiero go załatać. Oprócz gwarancji że ten bug nie pojawi się ponownie, niejako naturalnie doprowadzasz do dobrego przekrycia najbardziej istotnych fragmentów aplikacji.

2 Likes