Я думаю, что лучший подход к внедрению модульных тестов — просто написать их. Часто это привилегия, которую мы имеем как разработчики. Однако, справедливости ради, иногда разработчики могут быть слишком догматичны в отношении модульных тестов. То, что делает или ломает новое мобильное приложение, скорее всего, не будет зависеть от того, произойдет ли сбой версии 1.0 один раз за 100 сеансов или один раз за 10 000 сеансов. …и вряд ли это будет связано с уверенностью разработчика X в рефакторинге через 6 месяцев. В проектах на ранних стадиях риск может заключаться в том, что приложение взлетит или нет, будет ли первая версия казаться правильной или неправильной в руках заинтересованных сторон, закончатся ли у компании средства и т. д. Я думаю, что разработчики должны быть открытыми и гибкими. в связи с этим и делают все возможное, чтобы определить, когда и когда не следует вводить большое количество модульных тестов.
Но в любом случае, вы просили историю модульного тестирования, и вот моя. Это происходит в компании, где недавний переход к новому техническому директору, выступающему за TDD, вызвал дискуссию о покрытии юнит-тестами. Я не помню, как это началось, и, возможно, сам технический директор не имел к этому никакого отношения. Я предполагаю, что это рассматривалось как возможность продвинуть компанию в направлении TDD. Вскоре появилась тенденция обвинять все больше и больше сообщений об ошибках в отсутствии модульных тестов. На данный момент я должен добавить, что у нас уже было несколько юнит-тестов в моей команде (iOS) и довольно много функциональных тестов (к сожалению).
Команда API (Ruby) была активным сторонником TDD, в то время как команды iOS и Android были более ¯\_(ツ)_/¯. Генеральный директор, не являющийся техническим специалистом, был в отчаянии, но начал все больше и больше склоняться к мысли, что, возможно, ошибки возникают из-за недостаточного количества модульных тестов. Этот аргумент также был выдвинут в то время, когда отдел контроля качества был нашим самым большим узким местом. Другими словами, обсуждение было больше направлено на внутренние сообщения об ошибках, поднятые QA, а не на производственные ошибки.
Я решил выяснить, какой лагерь был прав, основываясь на реальных данных. Я провел выходные, просматривая все сообщения об ошибках iOS за 3 месяца. Моя цель состояла в том, чтобы сгруппировать все запросы в две категории — «могло» и «не могло» быть решено путем добавления дополнительных модульных тестов. Я ожидал, что категория «не смог» будет больше, но результат меня все равно удивил. Оглядываясь назад, НОЛЬ ошибок можно было бы решить, добавив больше модульных тестов. Вместо этого я обнаружил, что подавляющее большинство ошибок было вызвано либо пропущенными, либо неверно истолкованными требованиями. Для меня это тоже было настоящим открытием. Хотя я знал, что требования время от времени пропускаются, я действительно не знал, что это было основной причиной, по которой Q.A позже сообщил об ошибке. Примером может быть неверный значок. …или он был анимирован или выложен неправильно. Помимо этого, были ошибки, которые требовали целой последовательности действий наперед, например, проблема Core Data, связанная с многопоточностью, которую мы изо всех сил пытались воспроизвести.
Урок был усвоен в тот день. Добавление дополнительных модульных тестов ничего бы не решило. Вместо этого мы ввели новую политику. В рамках проверки кода рецензент также должен был прочитать требования к функциям и показать отладочную сборку ответственным разработчиком (быстро). Поначалу координировать работу было неприятно, но в конце концов это окупилось, и нагрузка на отдел обеспечения качества в конечном итоге была снижена до комфортного уровня.
