Moja firma jest całkiem nowa w jednostce testującej nasz kod. Od pewnego czasu czytam o TDD i testach jednostkowych i jestem przekonany o ich wartości. Próbowałem przekonać nasz zespół, że TDD jest wart wysiłku, aby nauczyć się i zmienić nasze nastawienie do sposobu, w jaki programujemy, ale jest to walka. Co prowadzi mnie do mojego pytania.

Jest wielu członków społeczności TDD, którzy są bardzo religijni w pisaniu testu, a następnie kodu (i jestem z nimi), ale dla zespołu, który boryka się z TDD, kompromis wciąż przynosi dodatkowe korzyści?

Prawdopodobnie uda mi się nakłonić zespół do napisania testów jednostkowych po napisaniu kodu (być może jako wymóg sprawdzania kodu), a moim założeniem jest, że nadal istnieje wartość w pisaniu tych testów jednostkowych.

Jaki jest najlepszy sposób na doprowadzenie zmagającego się zespołu do TDD? A jeśli to się nie uda, czy nadal warto pisać testy jednostkowe, nawet jeśli po napisaniu kodu?

EDYTOWAĆ

To, co od tego zabrałem, to to, że ważne jest dla nas rozpoczęcie testów jednostkowych, gdzieś w procesie kodowania. Dla osób z zespołu, które podchwycą tę koncepcję, zacznij iść bardziej w kierunku TDD i najpierw testować. Dzięki za wkład wszystkich.

ZAGRYŹĆ

Niedawno rozpoczęliśmy nowy mały projekt, a niewielka część zespołu wykorzystała TDD, reszta napisała testy jednostkowe po kodzie. Po zapakowaniu części kodu projektu, te piszące testy jednostkowe po kodzie były zaskoczone, widząc już wykonane kodery TDD i bardziej stabilny kod. To był dobry sposób na zdobycie sceptyków. Nadal mamy wiele rosnących bólów, ale bitwa testamentów wydaje się być zakończona. Dziękujemy wszystkim, którzy udzielili porady!