Юнит-тестирование Новичкам необходимо юнит-тестирование

Практика на существующих ошибках/дефектах.

Это действительно сложная ситуация. Я никогда раньше не переходил к TDD из ничего, но, по моему опыту, заставить команду перейти от отсутствия юнит-тестов к их активному написанию - это очень сложный подход "шаг за шагом".

Во-первых, приучите их писать модульные тесты, чтобы они знали, что это такое и в чем их польза. В моих командах было лучше всего писать модульные тесты для существующих ошибок. У существующих ошибок в системах есть две вещи, которым нужно научить людей, чтобы хорошо писать модульные тесты:

1. ожидаемое предусловие и постусловие
2. результат, который в данный момент не является тем, что ожидается, и нарушает данное предусловие/постусловие

Это дает участникам очень конкретные практические примеры. Они могут написать тест до исправления ошибки, чтобы он не сработал. Затем они могут исправить код так, чтобы он прошел и исправил ошибку. Когда они освоят это, вы сможете довести их до конца, чтобы они могли писать модульные тесты без кода, а затем писать новый код, чтобы тесты прошли.

Я думаю, что фокус в том, чтобы дать им что-то для практики, где есть четкие предварительные и последующие условия метода. Если требования к методам нечеткие, даже опытным TDD-специалистам трудно понять, с чего именно начать. Делайте шаг за шагом, и у вас все получится. Удачи!

Прикрепляю к посту несколько видео по теме:

Прикрепленное видео 1 - Unit-тесты не нужны

Прикрепленное видео 2 - Курс Тестирование ПО. Занятие 22. Unit Testing. Практические примеры, QA START UP

Прикрепленное видео 3 - Unit-тестирование (основы)