Основная проблема с унаследованным кодом состоит в том, что у него нет тестов. Так что вам нужно добавить немного (а потом еще ...).
Это само по себе потребует много работы, как отметил @mattnz. Но особая проблема унаследованного кода заключается в том, что он никогда не был разработан для тестирования . Поэтому, как правило, это огромный запутанный беспорядок в коде спагетти, в котором очень трудно или даже невозможно выделить мелкие детали для тестирования модулем. Поэтому перед модульным тестированием вам необходимо провести рефакторинг кода, чтобы сделать его более тестируемым.
Однако, чтобы безопасно выполнить рефакторинг, вы должны пройти модульные тесты, чтобы убедиться, что вы ничего не сломали со своими изменениями ... Это уловка 22 унаследованного кода.
Книга научит вас, как вырваться из этого улова, сделав абсолютно минимальные, самые безопасные изменения в коде, чтобы включить первые модульные тесты. Они не предназначены для того, чтобы сделать дизайн лучше, только для того, чтобы включить модульные тесты. На самом деле, иногда они делают дизайн более уродливым или более сложным. Тем не менее, они позволяют вам писать тесты - и как только у вас появятся модульные тесты, вы сможете улучшить дизайн.
Есть много хитростей, чтобы сделать код тестируемым - некоторые очевидны, а некоторые нет. Есть методы, о которых я бы никогда не подумал, не читая книгу. Но что еще более важно, это то, что Feathers объясняет, что именно делает код тестируемым. Вам необходимо сократить зависимости и ввести барьеры в ваш код, но по двум причинам:
- восприятие - для проверки и проверки результатов выполнения фрагмента кода, и
- разделение - для того, чтобы в первую очередь поместить конкретный кусок кода в тестовый комплект.
Безопасное сокращение зависимостей может быть сложным. Знакомство с интерфейсами, макетами и Dependency Injection - это чистая и приятная цель, просто не обязательно безопасная на данном этапе. Поэтому иногда нам приходится прибегать к подклассу тестируемого класса, чтобы переопределить некоторый метод, который обычно, например, запускает прямой запрос к БД. В других случаях нам может даже понадобиться заменить класс зависимости / jar на поддельный в тестовой среде ...
Для меня самая важная концепция, предложенная Feathers, это швы . Шов - это место в коде, где вы можете изменить поведение вашей программы без изменения самого кода . Встраивание швов в ваш код позволяет отделить тестируемый фрагмент кода, но также позволяет вам почувствовать поведение тестируемого кода, даже если это трудно или невозможно сделать напрямую (например, потому что вызов вносит изменения в другой объект или подсистему). , чье состояние невозможно запросить непосредственно из метода теста).
Это знание позволяет вам увидеть семена тестируемости в самой отвратительной куче кода и найти минимальные, наименее разрушительные, самые безопасные изменения, чтобы туда попасть. Другими словами, чтобы избежать «очевидных» рефакторингов, которые могут привести к поломке кода без вашего ведома, потому что у вас еще нет модульных тестов, чтобы обнаружить это.