Рефакторинг и разработка через тестирование

1. • Да, создайте новые тесты для новых методов.

   • Я видел бы 1/10 секунды как цель, за которую необходимо бороться. Более медленный тест не еще намного лучше, чем никакой тест.

2. Попытайтесь не изменить код и тест одновременно. Всегда делайте небольшие шаги.

0,1 раза модульного теста с довольно глупы. Нет никакой причины, модульные тесты не должны использовать сетевой сокет, считать большой файл или другие значительные операции, если они имеют к. Да хорошо, если тестовый прогон быстро, таким образом, можно продолжить основное задание записи приложения, но намного более хорошо закончиться с лучшим результатом в конце и если это означает выполнять модульный тест, который занимает 10-е затем, это - то, что я сделал бы.

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

Вот мое взятие на нем:

1. Нет и да. Первые вещи сначала состоят в том, чтобы иметь модульный тест, который проверяет вывод тех 500 методов строки. И затем это только, когда Вы начинаете думать о разделении его. Идеально процесс пойдет как это:

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

   После этого долгого процесса Вы поймете, что он мог бы иметь смысл, что некоторые методы быть перемещенным в другое место, или являются повторяющимися, и несколько могут быть уменьшены до единственной функции; это - то, как Вы знаете, что успешно выполнились. Редактирование тестирует соответственно.

2. Идите вперед и осуществите рефакторинг, но как только необходимо измениться, подписи вносят изменения в тесте сначала перед внесением изменения в фактическом коде. Тем путем Вы удостоверяетесь, что все еще делаете корректные утверждения, учитывая изменение в сигнатуре метода.

Вопрос 1: "Когда я разделил эту функцию, я создаю новые тесты для каждого нового метода/класса, который заканчивается?"

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

Вопрос 2: "Что происходит, когда код пересмотрен так, что структурно он больше не напоминает исходный код?"

Мой первый совет здесь - то, что необходимо получить хороший IDE и иметь хорошее знание регулярных выражений - пытаются сделать как можно больше рефакторинга с помощью автоматизированных инструментов. Это может помочь сэкономить время, если Вы достаточно осторожны для не представления новых проблем. Как Вы сказали, необходимо ли изменить модульные тесты - но если Вы использовали хорошие принципалы ООП с (Вы сделали правильно?), затем это не должно быть настолько болезненно.

В целом, важно спросить себя относительно осуществления рефакторинг преимуществ, перевешивают затраты? Я просто вожусь с архитектурой и проектами? Я делаю осуществление рефакторинг для понимания кода, и он действительно необходим? Я консультировался бы с коллегой, который знаком с кодовой базой для их мнения о стоимости/преимуществах Вашей текущей задачи.

Также помните, что теоретический идеал, который Вы читаете в книгах, должен быть сбалансирован с бизнес-потребностей реального мира и расписаний.

Когда у Вас есть длинный метод прежней версии, который делает X (и возможно Y и Z из-за его размера), реальный прием не повреждает приложение путем 'фиксации' его. Тесты на приложении прежней версии имеют предварительные условия и постусловия и таким образом, необходимо действительно знать их перед движением, разбивая его. Тесты помогают упростить это. Как только Вы повреждаете тот метод в два или больше новых метода, очевидно, необходимо знать пред/сообщение состояния для каждого из тех и таким образом, тесты для тех 'сохраняют Вас честными' и позволяют Вам спать лучше ночью.

Я не склонен волноваться слишком много о 1/10-м из второго утверждения. Скорее цель, когда я пишу модульные тесты, состоит в том, чтобы покрыть все мои базы. Очевидно, если тест занимает много времени, это могло бы быть, потому что то, что тестируется, является просто слишком большим количеством кода, делающего слишком очень.

Нижняя строка - то, что Вы определенно не хотите брать то, что является, по-видимому, рабочей системой, и 'зафиксируйте' ее до такой степени, что она иногда работает и перестала работать при определенных условиях. Это - то, где тесты могут помочь. Каждый из них ожидает, что мир будет в одном состоянии в начале теста и новом состоянии в конце. Только можно знать, корректны ли те два состояния. Все тесты могут 'передать', и приложение может все еще быть неправильным.

Каждый раз, когда код изменяется, тесты возможно изменятся, и новые должны будут, вероятно, быть добавлены для обращения к изменениям, внесенным в производственный код. Те тесты работа с текущим кодом - не имеет значения, должны ли параметры были измениться, существуют все еще пред/сообщение условия, которые нужно соблюдать. Это не достаточно, очевидно, чтобы просто разбить код в меньшие блоки. 'Аналитик' в Вас должен смочь понять систему, которую Вы создаете - это - задание один.

Работа с унаследованным кодом может быть реальной тяжелой работой в зависимости от 'путаницы', с которой Вы запускаете. Я действительно нахожу, что знание, что Вы имеете и что оно, как предполагается, делает (и ли оно на самом деле делает это на шаге 0, прежде чем Вы начнете осуществлять рефакторинг его) является ключевым для успешного рефакторинга кода. Одна цель, я думаю, состоит в том, что я должен смочь выбросить старый материал, прикрепить свой новый код в его место и иметь его работа, как рекламируется (или лучше). В зависимости от языка это было записано в, предположения, сделанные исходным автором (авторами) и способностью инкапсулировать функциональность в containable блоки, это может быть реальный прием.

Всего наилучшего