Во время разработки не было никакого процесса разработки, управляемого тестами, из-за очень сжатых сроков
Это утверждение очень волнующее. Не потому, что это означает, что вы разработали без TDD или потому, что вы не все тестируете. Это касается, потому что это показывает, что вы думаете, что TDD замедлит вас и заставит вас пропустить крайний срок.
Пока вы видите это таким образом, вы не готовы к TDD. TDD - это не то, что вы можете постепенно облегчить. Вы либо знаете, как это сделать, либо нет. Если вы попытаетесь сделать это на полпути, вы сделаете это, и вы будете выглядеть плохо.
TDD - это то, что вы должны сначала практиковать дома. Научитесь делать это, потому что это помогает вам писать код сейчас . Не потому, что кто-то сказал тебе это делать. Не потому, что это поможет, когда вы внесете изменения позже. Когда это становится чем-то, что вы делаете из- за спешки, тогда вы готовы сделать это профессионально.
TDD - это то, что вы можете сделать в любом магазине. Вам даже не нужно сдавать свой тестовый код. Вы можете оставить это при себе, если другие презирают тесты. Когда вы делаете это правильно, тесты ускоряют вашу разработку, даже если никто не запускает их.
С другой стороны, если другие любят и проводят ваши тесты, вы должны помнить, что даже в магазине TDD проверять тесты не ваша задача. Это для создания проверенного рабочего производственного кода. Если это будет проверяемым, аккуратно.
Если вы думаете, что руководство должно верить в TDD или что ваши коллеги-кодировщики должны поддерживать ваши тесты, то вы игнорируете лучшее, что TDD делает для вас. Он быстро показывает разницу между тем, что, по вашему мнению, делает ваш код, и тем, что он делает на самом деле.
Если вы не видите, как это само по себе может помочь вам уложиться в срок быстрее, тогда вы не готовы к работе с TDD. Вы должны практиковаться дома.
Тем не менее, хорошо, когда команда может использовать ваши тесты, чтобы помочь им прочитать ваш рабочий код, и когда руководство купит изящные новые инструменты TDD.
Это хорошая идея написать все возможные тестовые случаи после преобразования команды в TDD?
Независимо от того, что делает команда, не всегда хорошая идея написать все возможные контрольные примеры. Напишите самые полезные контрольные примеры. 100% покрытие кода происходит за плату. Не игнорируйте закон убывающей доходности только потому, что сложно судить.
Сэкономьте энергию для интересной бизнес-логики. Материал, который принимает решения и обеспечивает соблюдение политики. Проверь это. Скучный очевидный, легко читаемый структурный код, который соединяет все вместе, не нуждается в тестировании.
(1) Это все еще нормально или хорошая идея - прекратить большую часть разработки и начать писать все возможные тестовые сценарии с самого начала, даже если все работает нормально (пока!)? Или
Нет. Это мышление "давайте сделаем полное переписывание". Это разрушает с трудом завоеванные знания. Не спрашивайте у руководства время написать тесты. Просто напишите тесты. Как только вы узнаете, что делаете, тесты не замедлят вас.
(2) лучше подождать, пока что-то плохое случится, а затем во время исправления написать новые модульные тесты, или
(3) даже забыть о предыдущих кодах и просто написать модульные тесты только для новых кодов и отложить все до следующего крупного рефакторинга.
Я отвечу 2 и 3 одинаково. Когда по какой-либо причине вы меняете код, очень приятно, если вы можете пройти тест. Если код является устаревшим, в настоящее время он не приветствует тест. Что означает, что это трудно проверить, прежде чем менять его. Ну, так как вы все равно меняете его, вы можете превратить его во что-нибудь тестируемое и протестировать.
Это ядерный вариант. Это рискованно. Вы вносите изменения без тестов. Существуют некоторые творческие приемы для проверки унаследованного кода перед его изменением. Вы ищите так называемые швы, которые позволяют изменять поведение вашего кода без изменения кода. Вы изменяете конфигурационные файлы, собираете файлы, что угодно.
Майкл Фезерс дал нам книгу об этом: эффективная работа с устаревшим кодом . Прочитайте его, и вы увидите, что вам не нужно сжигать все старое, чтобы сделать что-то новое.