Можете ли вы самостоятельно проверить вид бритвы без необходимости проведения интеграционных испытаний?

У меня есть веб-сайт MVC с множеством различных шагов, которые пользователь должен предпринять, чтобы пройти через него. Существуют проверки проверки и временные разделы (для юридических требований). Для проведения теста интеграции каждый раз, когда мне нужно протестировать небольшое изменение на странице, это настоящая головная боль. В идеале, я хочу знать, есть ли способ (возможно, плагин?), Который позволит мне щелкнуть правой кнопкой мыши по виду, как-то указать поддельный объект модели и открыть его напрямую?

В конечном итоге я хочу проверить, как выглядит любой новый скрипт на стороне клиента (который сочетает в себе бритву /javascript/jQuery ) и работает в разных браузерах. Речь идет не о функциональности тестирования моих контроллеров.

Ответ 1

Данные о времени разработки

Данные о времени разработки обычно используются в WPF, здесь есть статья, в которой описывается техник для отображения данных времени разработки в MVC:

http://blog.dezfowler.com/2010/11/adding-design-mode-to-your-mvc-app.html

Это должно предоставить вам метод "как-то указать поддельный объект модели и открыть его напрямую".

Это может быть все, что вам нужно, или:

Curl

Может использоваться с данными реального времени или времени разработки, как указано выше.

Я использую cURL, выполненный из пакетных файлов, и вывод содержимого в несколько файлов.

Например, эта партия может моделировать вход в систему:

logon.bat:

echo Index without logon
curl http://localhost/index.html
echo Logon
curl http://localhost/login.html --data "username=a&password=p" ---dump-header auth.txt
echo Index after logon
curl http://localhost/index.html --cookie auth.txt

RunAll.bat:

call Logon.bat > logon_result.txt

В первый раз, когда я запускаю его, я также вручную просматриваю страницы в браузере, тогда я знаю, что могу выполнить эти файлы пакетного результата (например, logon_result.txt) в качестве ожидаемого результата.

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

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

Я поймал некоторые плохие ошибки с этим techinque. Когда-либо ставьте System.Web.Mvc.AuthorizeAttribute на ApiController вместо System.Web.Http.AuthorizeAttribute? Не блокирует неавторизованных пользователей, но код выглядит нормально.

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

Ответ 2

Тестирование веб-приложения - довольно большая тема, но позволяет сохранить его просто:

Чтобы правильно протестировать приложение, вам необходимо разработать приложение таким образом

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

Если у вас есть веб-сайт MVC, вам обычно необходимо, чтобы вся бизнес-логика была отделена от любого пользовательского интерфейса. Это фактически должно позволить вам использовать стандартные unit test проекты для тестирования, скажем, 80% вашего кода. Из-за этого вам нужно написать много кода, чтобы проверить его правильно...

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

В общем, он работает так: вы определяете действия, которые обычно выполняете как пользователь в веб-браузере. Все действия, которые должен выполнить пользователь, могут быть протестированы, скриптируя его. Чтобы сделать это, это сильно зависит от того, насколько сложным и/или динамическим является ваш пользовательский интерфейс. Чем больше у вас фантазии, тем труднее будет написать тест script...

Ниже приведены некоторые замечательные статьи об автоматизации тестирования: http://visualstudiomagazine.com/Articles/2012/12/01/Automated-UI-Testing.aspx

http://blog.typemock.com/2012/05/22/automated-testing-of-asp-net-mvc-applications

Здесь также приведено быстрое видео о том, как получить автоматические тесты пользовательского интерфейса, запущенные в VS2012: http://channel9.msdn.com/Events/Visual-Studio/Visual-Studio-2012-Virtual-Launch/Automated-UI-testing-with-Visual-Studio-2012