Стратегия модульного тестирования и рефакторинга существующего приложения Grails

Question

Какую стратегию вы бы порекомендовали для модульного тестирования существующего приложения Grails?
Я только что прочитал книгу Бека Кента по TDD и хотел бы применить подобный подход к моему приложению. Моя цель состоит в том, чтобы провести модульное тестирование всей кодовой базы и иметь возможность реорганизовать код и сделать его «чище». Под «чище» я подразумеваю, что хочу уменьшить дублирование, сделать свои контроллеры более тонкими, извлекая общую логику в службы и т. Д.
Так с чего мне начать? Модели? Контроллеры?
Каков ваш «плохой» и «хороший» опыт в подобных вещах?

@ Петер. Мое приложение не слишком большое, на мой взгляд. он состоит из 12+ моделей, аналогичного количества контроллеров, нескольких сервисов и около 15 классов утилит.
Одна из основных причин, по которой я хочу получить полное покрытие модульных тестов, заключается в том, что во многих случаях система просто работает. Хотя это хорошо с точки зрения пользователя, с точки зрения разработчика, такой код - это кошмар, который нужно менять и поддерживать.
Еще одна важная вещь: я бы хотел делать небольшие и быстрые регулярные выпуски (новые небольшие функции и / или улучшения), но без охвата модульных тестов это было бы практически невозможно.
Так что вопрос не в том: «Нужно ли мне это делать?», А « Как я могу это сделать ?»

Answer 1

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

Хороший метод - писать модульные тесты более или менее в стиле TDD всякий раз, когда вам нужно прикоснуться к какой-либо части кода.Я написал «более или менее», потому что для унаследованного кода вам, как правило, нужно писать более высокоуровневые, более сложные модульные тесты, чем для разработки с нуля.На самом деле, в некоторых случаях начинать с модульных тестов может даже не быть продуктивным, вместо этого лучше создавать функциональные / системные тесты для охвата крупномасштабной функциональности с точки зрения пользователя.

Обратите внимание, что в зависимости отИмея доступную документацию и уровень знаний разработчика / пользователя о системе, вы не всегда сможете определить «правильное» поведение для конкретной функции, только ее текущее поведение.Даже в этом случае стоит покрыть его (модульными) тестами: они документируют реальное поведение кода и выявляют любые неожиданные изменения в нем в будущем.

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

Answer 2

Я в целом согласен с @Peter в том, что это нетривиальная вещь, и вам может помешать просто знать, что делают, а не то, что они должны делать.Но это нормально, если не идеально, потому что тестирование так же важно для удобства сопровождения (то есть, чтобы знать, когда изменения ломают вещи), так же как и для правильности.Поэтому поставьте тесты вокруг существующей функциональности, как она есть сейчас, и если вам нужно исправить ошибку, вы можете изменить свой тест, чтобы зафиксировать исправление.

Если вы и ваша команда сосредоточены на добавлении новых функций,затем внедрите TDD сейчас, то есть протестируйте новую функциональность и добавьте в тесты существующую функциональность, которую вы модифицируете, как уже было предложено.

Если вы можете сосредоточиться на тестировании, то я бы тестировал в вертикальных слоях.Напишите несколько тестов для модели, затем ее сервисов, затем контроллеров (этот порядок - только предложение).Суть в том, что если вы тестируете часть книги в своем приложении, протестируйте все функциональные возможности книги, прежде чем двигаться дальше.Кроме того, вы можете расставить приоритеты по основным функциям приложения.Если «Книги» гораздо важнее, чем что-то еще, сначала проверьте «Книги».

Answer 3

Лично мне было проще всего провести интеграционное тестирование Grails.Только для некоторых часто используемых бобов я проводил модульное тестирование.Признаюсь, это не очень TDD, но все же дает вам некоторую уверенность.