Конвертировать приложение .NET в приложение, управляемое тестами

Question

У меня есть старое приложение WinForm, написанное на .NET 2.0. Приложение не следует ни шаблону, ни шаблону слоя. Мой клиент сейчас хочет внедрить модульное тестирование Framework. Как это живое приложение, так что очень рискованно переписывать весь код снова. Какой подход я должен следовать?

Заранее спасибо

Answer 1

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

«Эффективная работа с устаревшим кодом»

http://books.google.ie/books?id=CQlRAAAAMAAJ&q=dealing+with+legacy+code&dq=dealing+with+legacy+code&hl=en&ei=LnVXTrviCtSu8QPEwei0DA&sa=X&oi=book_result&ct=result&resnum=1&ved=0CC0Q6AEwAA

Answer 2

Это зависит от того, что вы хотите проверить, и как написано приложение.

GUI сложно протестировать, но посмотрите некоторые другие ответы. Если, как я подозреваю, вы просто хотите протестировать бизнес-уровень, это проще:

Если в приложении отсутствует бизнес и графический интерфейс пользователя, вы можете легко использовать NUnit, либо интегрировав его в проект из вашей IDE, либо собственным способом NUnit, а затем написать тесты, чтобы охватить, какие функции бизнес-уровень предоставляет GUI.

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

Answer 3

Я бы порекомендовал вам переместить наиболее важные части в обычные классы C # и протестировать их. И только потом тестирование пользовательского интерфейса на сложных частях графического интерфейса. Я работал над устаревшим проектом, но с веб-формами ASP.NET вместо Windows Forms, и я заметил, что некоторые части системы часто менялись и были хорошими кандидатами на рефакторинг и модульное тестирование, в то время как другие части никогда не менялись и просто не стояли усилие тестирования.

Если это большой проект, то это может занять много времени. Огромная часть работы заключается в том, чтобы сделать код тестируемым и внедрить некий шаблон MVP ( Model-View-Presenter ), чтобы иметь возможность отделить код GUI от бизнес-логики.

Я бы настоятельно рекомендовал эффективно работать с устаревшим кодом, как рекомендует Эойн Кэрролл. Он описывает методы работы с унаследованным кодом, а также обеспечивает мотивацию (вы можете быть в трудные времена), показывая, что это может быть сделано.

Также взгляните на эти два вопроса StackOverflow ( здесь и здесь ) для обсуждения WinForms и MVP.

Answer 4

Чтобы выполнять только тесты пользовательского интерфейса (поскольку он основан на .net), вы можете использовать .Net облегченную функцию автоматизации тестирования. Подробности здесь http://msdn.microsoft.com/en-us/magazine/cc163864.aspx Вам не нужно использовать внешний инструмент для его автоматизации. Но опять же, чтобы протестировать нижележащие уровни или бизнес-логику, вам нужно расширить контрольные примеры.

Answer 5

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

Возможно, вы захотите взглянуть на:

http://smartbear.com/products/qa-tools/automated-testing/supported-testing-types/functional-testing/

Answer 6

В WinForms действительно сложно провести модульное тестирование, потому что код тесно связан с самим графическим интерфейсом.Некоторые тесты автоматизации, вероятно, будут лучшими, что вы можете получить в приложении WinForms, не пытаясь изменить программу.

Если вашему клиенту нужно тестируемое решение, я бы предложил сделать его в WPF и использоватьФреймворк MVVM, такой как Caliburn.Micro, который подчеркивает модульное тестирование.

К сожалению, это означает переписывание всего приложения.

Краткий ответ

Переписать любое приложение,или не слишком заморачивайтесь с юнит-тестами.