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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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