Модульное тестирование огромных приложений - проверенные методологии?

Question

Последние 10 месяцев я работаю в приложениях Windows Forms и ASP.Net. Мне всегда было интересно, как правильно выполнить модульное тестирование всего приложения, охватывающего все сценарии. У меня есть следующие вопросы относительно них -

• Каковы стандартные механизмы в выполнение юнит-тестирования и написание контрольных примеров?
• Меняются ли методологии на основе о характере применения, таких как Windows Forms, веб-приложения и т. Д.
• Какой наилучший подход сделать уверены, что мы рассмотрим все сценарии? любой популярные книги по этому поводу?
• Популярные инструменты для выполнения юнита тестирование

Answer 1

Я рекомендую очень хорошую книгу на эту тему: Эффективная работа с устаревшим кодом от Michael Feathers. Я нашел это чрезвычайно полезным для подобных устаревших проектов.

Основная проблема с унаследованным кодом заключается в том, что не существует «стандартного» способа его модульного тестирования :-( «Стандартная» разработка через тестирование придумана для новых проектов, где вы начинаете писать код - и модульные тесты - с нуля. Таким образом, вы можете расширить свой набор модульных тестов вместе с вашим кодом с первого дня и постоянно поддерживать весь (или большую часть) вашего кода.

Однако реальность такова, что в большинстве реальных проектов используется устаревший код без единого модульного теста (на самом деле определение устаревшего кода , разработанное Feathers, - это «код без модульных тестов»). Эта книга полна полезных советов о том, что делать, когда вам нужно коснуться кода, который вы едва понимаете, или изменить метод монстра из 1000 строк и убедиться, что, по крайней мере, ваша модификация прошла модульное тестирование должным образом. В таких случаях, как правило, очень сложно писать модульные тесты, потому что код не предназначен для тестирования. Так часто вам приходится реорганизовывать его, чтобы сделать его тестируемым, но, конечно, без проведения модульных тестов это рискованно ... тем не менее, есть выходы из таких ловушек, и эта книга показывает их.

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

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

Answer 2

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

Модели тестирования, такие как V-Model, определяют как минимум три фазы тестирования:

Модульное тестирование

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

Интеграционное тестирование

Как только вы подтвердите, что каждый из ваших "единицы" (классы или методы) работают индивидуально, попробуйте сейчас проверить, вся система работает как единое целое. Так вы делаете интеграционный тест, который проверяет, работают ли эти устройства правильно вместе, чтобы достичь цель системы. Вам следует попробуйте автоматизировать интеграционные тесты как Что ж. Вы можете использовать такие инструменты, как StoryTeller за это.

Приемочное тестирование пользователя

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

Теперь, чтобы ответить на ваши вопросы:

Каковы стандартные механизмы выполнения модульного тестирования и написания контрольных примеров?

Для этой цели вам следует использовать .Net Test Units. Чтобы протестировать взаимодействие с пользователем (вы можете протестировать взаимодействие с пользователем на экране), вы можете использовать внешнее приложение (проверьте ссылки ниже). Какой-то робот может автоматизировать такие тесты для вас.

Меняются ли методологии в зависимости от характера приложений, таких как Windows Forms, веб-приложения и т. Д.?

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

Каков наилучший подход, чтобы убедиться, что мы охватываем все сценарии? Какие-нибудь популярные книги на эту тему?

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

Популярные инструменты для выполнения модульного тестирования?

Список инструментов тестирования GUI

Список структур модульного тестирования

Надеюсь, это поможет.

Answer 3

Каковы стандартные механизмы выполнения модульного тестирования и написания контрольных примеров? Существует множество платформ для тестирования .NET. Я бы порекомендовал вам дать NUnit или MbUnit.

http://www.nunit.org/

http://www.mbunit.com/

MbUnit будет поставляться с тестовым раннером, так что это может упростить задачу. Я предпочитаю комплексный подход, при котором я могу запускать все свои тесты прямо из Visual Studio, но это требует значительных настроек. При использовании тестового прогона (такого как Gallio, который поставляется с MbUnit) вы будете запускать свои юнит-тесты вне вашего проекта Visual Studio. Сами юнит-тесты должны располагаться внутри собственного проекта, как правило, в форме Fixture. Тесты внутри могут быть названы разными стилями, но ключ должен быть как можно более описательным. Например:

void when_my_class_is_sent_a_user_it_should_save_it()

Также популярно

[MethodName_StateUnderTest_ExpectedBehavior]

Меняются ли методологии в зависимости от характера приложения, такого как Windows Forms, веб-приложения и т. Д.? Методология меняется в зависимости от характера приложения. К счастью, веб-формы и формы выигрышей очень похожи. К сожалению, оба они были разработаны без тестирования и склонны к коду, который трудно протестировать должным образом.

Каков наилучший подход для обеспечения охвата всех сценариев? Test Driven Design (вы пишете тесты, а затем пишете код, чтобы они прошли успешно). Покрытие кода также может быть полезным показателем.

Какие-нибудь популярные книги по этому поводу? Искусство модульного тестирования: с примерами в .Net Рой Ошерове Прагматическое модульное тестирование в C # с NUnit

Популярные инструменты для выполнения модульного тестирования? Как уже упоминалось выше, NUnit & MbUnit. Есть также MSTest (поставляется в комплекте с VS2008), xUnit и некоторые другие. Настоятельно советую вам пойти с NUnit или MbUnit.

Answer 4

Вам нужно написать модульные тесты, которые проверяют объекты и функциональность в вашей программе. Это означает тесты для проверки каждой функции внутри класса, затем функциональности класса в целом, а затем функциональности внутри библиотек. По сути, вы пишете тесты для каждого уровня приложения прямо от библиотек верхнего уровня до функций. Это гарантирует, что если вы измените ЛЮБОЙ код, он все равно будет работать как положено.

NUnit является популярной платформой для модульного тестирования, но VS стандартно предоставляет вам встроенные модульные тесты (может быть только для VS2008, но вполне уверен, что VS2005 тоже)

Покрытие всех сценариев - это просто случай написания тестов для охвата всех известных событий, вы не можете охватить КАЖДЫЙ сценарий, но вы можете охватить основные сценарии, которые обычно хороши, если вы знаете, какой результат ожидается, и можете проверить его. 1005 *

Answer 5

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

На этом этапе вам лучше написать автоматические приемочные тесты с использованием таких инструментов, как FitNesse или StoryTeller .