Можете ли вы самостоятельно проверить вид бритвы без необходимости проведения интеграционных испытаний?
У меня есть веб-сайт 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
