Единица тестирования «устаревшего» приложения WPF

Question

Продукт, над которым я работал, находится в разработке в течение последних шести лет. Он начался как общий портал ввода данных в безумно сложную часть WPF/часть старого приложения. Система была разработана на протяжении всех этих лет без единого теста на единицу. Теперь вопрос поднят для всеобъемлющей структуры тестирования модулей. Недавно я был нанят для работы над этим продуктом, и мне было поручено привести «Тестирование» в порядок. Поскольку команда, которая работала над продуктом в течение последних шести лет, приняла «Agile», в проекте отсутствует документация о бизнес-правилах или каких-либо проектных документах.

Я пытался написать модульные тесты для некоторых модулей. Но я не уверен, что делать Mock, как настроить тестовое оборудование и, в конце концов, что тестировать, поскольку случайный взгляд на методы не раскрывает его намерений. Кроме того, мне было пришло в голову, что код не был разработан с учетом конкретной методологии.

Учитывая сложившуюся ситуацию, мне было интересно, могут ли хорошие люди Stackoverflow предоставить мне некоторые советы о том, как спасти эту ситуацию. Я слышал о книге «Работа с устаревшим кодом», которая может что-то сказать об этой общей ситуации, но я думал о том, чтобы получить некоторые указатели от людей, столкнувшихся с подобными ситуациями в стеке технологий (C#, VB, C++, NET 3.5 , WCF, SQL Server 2005).

Answer 1

На мой взгляд, лучший способ - начать с «стабилизации» текущей функциональности кода, используя интеграционные тесты. Попробуйте создать тесты, которые имеют начальную точку, которая вряд ли изменится позже. Используя интеграционные тесты, вы можете получить уверенность в том, что рефакторинг, который выйдет позже для модульных тестов, не нарушает ничего.

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

Это очень рекомендуется прочитать Работа с унаследованным кодом, многие из проблем, которые вы собираетесь встретить уже есть решения :)

Unit тестирование унаследованного кода может быть вызов иногда, в зависимости от существующего кода и на сколько вы можете изменить код. Вы можете использовать некоторые инструменты, например, для написания интеграционных тестов вы можете использовать фреймворк White для автоматизации графического интерфейса. Еще один инструмент, который вы можете использовать для написания модульных тестов без существенных изменений кода: TypemockIsolator (отказ от ответственности - я работаю на Typemock), он позволяет подделывать большую часть зависимостей без изменения производственного кода. Есть много других инструментов, которые могут облегчить процесс, попытаться найти и наилучшим образом использовать их :)

Answer 2

@sc_ray: Я знаю, это может показаться довольно очевидным, но я считаю, что перед началом написания тестов с существующей базой кода вам следует сосредоточиться на том, чтобы вы использовали подход MVVM при взаимодействии с вашим пользовательским интерфейсом.
Быть устаревшим приложением не означает, что у вас есть код, обновляющий интерфейс непосредственно с операторами if, но чем старше проект, тем легче людям обойти более современные стили разработки программного обеспечения.
Все, что я говорю, это то, что я буду следить за тем, чтобы оптимизировать использование привязки, командования и всех замечательных инфраструктурных объектов WPF. В противном случае важные части вашей бизнес-логики не смогут быть протестированы, и вы можете потенциально написать тесты против менее релевантного кода ...