W zyskającym wciąz na popularności Test Driven Development można doszukać się pewnej wady: testy jednostkowe i kod pisane są przez programistę, często tę samą osobę. W konsekwencji jakość oprogramowania może być zagrożona gdy programista będzie konstruował testy w taki sposób, aby odpowiadały one jego kodowi. Nie na darmo w wielu przypadkach proces testowania powierza się osobom nie piszącym kodu. A gdyby programiści pisali kod tak, aby spełniał on przypadki testowe sporządzone przez testerów?

W projekcie, w którym pracuję, wprowadziliśmy pojęcie krytycznego przypadku testowego, który musi zostać wykonany przez programistę i zakończony powodzeniem, zanim funkcjonalność trafi na środowisko testowe. Naszą motywacją była przede wszystkim chęć przeciwdziałania sytuacjom, w których nowe funkcjonalności w środowisku testowym blokowały podstawowe funkcje programu uniemożliwiając testowanie.

O początkowych problemach, wpływie na projekt, zespół jak i końcową jakość produktu, chciałabym opowiedzieć Państwu podczas mojej prezentacji.

Tagged under:

@ArnikaHryszko metodyka TDD test case driven development