@loza_szydercow @LukeJL
Odpowiadam w poscie, bo miejsca potrzebuję
"Testy testów to kod, TDD to relacja dwustronna. Jak masz skopane testy to kod, który próbujesz napisać, to wykaże" - ja widziałem skopane testy które nigdy nie failowały tylko dlatego że ktoś zmienił charakter testowanego kodu na asynchroniczny i skoro nie miał faila to uznał że test jest ok. Ciekawe ile takich false positive testów siedzi w dużych projektach.
Zmiana kodu na asynchroniczny to nie jest nieinwazyjny refaktor, więc (zgodnie z TDD) zanim się taką zmianę wykona należy zmienić powiązane z tym kodem testy, tj. zmodyfikować je tak by obsłużyły nową wersję i co za tym idzie zfailowały. Wtedy nie masz sytuacji, że testy źle napisane i przechodzą.
Zdarzyło mi się na CR widzieć np takie kwiatki (uwaga JS, ale prosty):
// function returns asynchronous result:
import someFunction from './some-function'
describe('some test suite', () => {
it('some test case with asynchronous behaviour', () => {
const input = 11
const actual = someFunction(input)
const expected = 121
expect(actual).to.eventually.equal(expected)
})
})
Test przechodzi, na pierwszy rzut (nieprzyzwyczajonego) oka nie widać błędu. W czym problem? Brakuje return
przed expect
, mocha wymaga returna jak testujesz promisy. Niby słabe, bo przez zwykłą nieuwagę (lub nieznajomość działania frameworka testującego) mamy wiecznozielone testy.
Ale!
Od razu widać, że testy zostały napisane po napisaniu kodu ;)
Ponownie, gdyby proces pisania kodu wyglądał następująco:
- piszemy testy i tylko tyle kodu by się skompilowało (czyli zazwyczaj puste funkcje jeśli chodzi o JS) ale żaden z testów nie przeszedł
- piszemy kod tak aby failujące do tej pory testy przeszły.
to ten pozornie trudny w wyłapaniu błąd jest wyłapany już na pierwszym etapie.