Начните с малого.
Модульное тестирование (и автоматическое тестирование в целом) не является серебряной пулей, не всегда применимо к любой ситуации и может быть небольшим культурным шоком. Тем не менее, если вы пишете программное обеспечение, которое вы продаете или на которое опирается ваша компания, я настоятельно рекомендую принять его. Вы будете удивлены, как много магазинов по профессиональному развитию не делают.
Во-первых, освоите механизмы создания и запуска модульных тестов с помощью инструментов разработки.
Затем начните с нового (желательно небольшого, но не обязательно тривиального) класса или метода, который вы хотите протестировать. Написание тестов для существующего кода имеет свои проблемы, поэтому вам следует начать с чего-то совершенно нового или с того, что вы собираетесь переписать.
Вы должны заметить, что создание этого класса или метода для тестирования (и, следовательно, для повторного использования) влияет на то, как вы пишете код. Вы также должны обнаружить, что размышления о том, как тестировать код заранее, заставляют задуматься и доработать дизайн сейчас, а не через какое-то время «когда времени больше». Такие простые вещи, как «Что должно быть возвращено, если передан неверный параметр?». Вы также должны чувствовать определенную уверенность в том, что код ведет себя именно так, как вы ожидаете.
Если вы видите выгоду от этого упражнения, то постройте его и начните применять его к другим частям вашего кода. Со временем вы будете все больше и больше доверять своему программному обеспечению, поскольку оно становится более правдоподобным.
Практический подход помог мне лучше разобраться в предмете, чем многие материалы для чтения, и помог заполнить пробелы в вещах, которые я просто не понимал. Особенно в том, что касается TDD. Это было нелогично, пока я не попробовал.