Od czego zaczac nauki testow (javascript)

Czesc, jestem poczatkujacym programista, pracuje w zawodzie 2 miechy dopiero, ale bardzo ciezko pracuje, 8h w pracy, a kolejne 8 w domu/pociagu (wszedzie), dlatego stawiam sobie wysoko poprzeczke i codziennie ostro sie ucze. W pracy zauwazylem ze umiejetnosc testow jest bardzo wazna i chcialbym wlasnie sie tego jak najpredzej nauczyc. Jako ze programuje w js-ie to chcialbym nauki testow od 0 wlasnie dla tego jezyka.

Pozdrawiam

mocha albo jasmine albo tape, moim zdaniem, jeśli chodzi o narzędzia przynajmniej.

jeśli pracujesz to warto zobaczyć jak kod jest testowany u ciebie, podpytać, ew. zobaczyć w projektach open source w jaki sposób są zorganizowane testy.

@LukeJL dzieki! a czy testowanie w angularze 1/2 , react rowniez tymi narzedziami mozna?

Krzywy Samiec napisał(a):

8h w pracy, a kolejne 8 w domu/pociagu (wszedzie),

Zacząłbym od odpoczynku :P

@Khuzy moze przesadzilem ze 8h ale 23 klade sie spac i jadac do pracy / wracajac i po kolacji siadam do programowania. Wiadomo, ze w w drodze do pracy nie programuje, ale programista to nie tylko klepanie kodu, wiec czytam rozne artykuly / ksiazki. Odpoczynek mam w weekendy, bo nie robie kompletnie nic w ta strone.

Ja bym na twoim miejscu zaczął od Tape / Ava, inne runnery są częściej stosowane (Mocha + Chai, Jasmine), ale mają trochę za uszami, mam podobną opinię co ten gość: https://medium.com/javascript-scene/why-i-use-tape-instead-of-mocha-so-should-you-6aa105d8eaf4#.xouou0ujt

Testowanie to bardzo szerokie zagadnienie - zacznij od nauki pisania dobrych testów jednostkowych, kilka moich spostrzeżeń:

• poczytaj o TDD i staraj się je w miarę możliwości stosować,
• test powinien testować tylko jedną rzecz na raz, zazwyczaj oznacza to jedną asercję per test (choć niekoniecznie),
• przygotowywuj zawsze minimalne niezbędne dane testowe, staraj się umieszczać je bezpośrednio w testach, nie w plikach zewnętrznych,
• nie bój się powtórzeń w testach, testy nie muszą być DRY - traktuj każdy test jako osobny mini-program, nigdy nie wydzielaj asercji do jakichś helperów itp - test powinnno się dać "przeczytać jak książkę",
• nigdy nie dziel stanu pomiędzy testami, testy muszą być odizolowane od siebie, kolejność ich odpalania nie może mieć znaczenia,
• trzymaj się silnie SRP, dzięki temu pisanie testów będzie łatwe (a kod lepszy),
• faworyzuj funkcje bez efektów ubocznych, pisanie do nich testów to bajka -> https://en.wikipedia.org/wiki/Pure_function
• no i wiadomo - pisz testy jednostkowe, nie jakieś hybrydy jednostkowo-integracyjno-funkcjonalno-niewiadomojakie ;)

Maciej Cąderek napisał(a):

• rób jedną asercję per test,

Nie podzielam tej opinii. Jutro jak znajdę czas to podam kontrprzykłady.