Разработка пользовательского интерфейса в JavaScript с использованием принципов TDD

У меня было много проблем, пытаясь придумать лучший способ правильно следовать принципам TDD при разработке пользовательского интерфейса в JavaScript. Каков наилучший способ сделать это?

Лучше ли отделять визуальный от функционала? Вы сначала разрабатываете визуальные элементы, а затем записываете тесты, а затем код для функциональности?

0
добавлено отредактировано
Просмотры: 26

7 ответы

0
добавлено

Я нашел архитектуру MVP очень подходящей для написания тестируемых пользовательских интерфейсов. Классы Презентатор и Модель могут быть просто протестированы на 100%. Вам нужно только беспокоиться о View (который должен быть немым, тонким слоем только для того, чтобы запускать события в Presenter) для тестирования пользовательского интерфейса (с Selenium и т. Д.),

Обратите внимание, что я говорю об использовании MVP полностью в контексте пользовательского интерфейса, не обязательно переходя на серверную сторону. У вашего пользовательского интерфейса может быть свой собственный презентатор и модель, которая полностью работает на стороне клиента. Presenter управляет логикой взаимодействия/проверки подлинности UI и т. Д., В то время как модель сохраняет информацию о состоянии и предоставляет портал для бэкэнд (где у вас может быть отдельная модель).

Вы также должны взглянуть на метод Presenter First TDD.

0
добавлено

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

Я только что выпустил инструментарий с открытым исходным кодом, который поможет с JavaScript tdd безмерно. Это композиция из многих инструментов с открытым исходным кодом, которая дает вам рабочее приложение requirejs.

Он предоставляет единые команды для запуска: веб-сервер dev, одиночный тестовый бегун jasmine single browser, jasmine js-test-driver multi browser test runner и конкатенирование/минимизация для JavaScript и CSS. Он также выводит неограниченную версию вашего приложения для производственной отладки, прекомпиляции ваших шаблонов руля и поддерживает интернационализацию.

Установка не требуется. Это просто работает.

http://github.com/davidjnelson/agilejs

0
добавлено

Я собираюсь начать Javascript TDD над новым проектом, над которым я работаю. Мой текущий план заключается в использовании qunit для проведения модульного тестирования. При разработке тестов можно запустить, просто обновив тестовую страницу в браузере.

Для непрерывной интеграции (и обеспечения выполнения тестов во всех браузерах) я буду использовать Selenium для автоматической загрузки теста жгут в каждом браузере и прочитать результат. Эти тесты будут выполняться при каждой проверке до источника.

Я также собираюсь использовать JSCoverage , чтобы получить анализ покрытия кода на основе кода. Это также будет автоматизировано с помощью Selenium.

В настоящее время я занимаюсь этим. Я уточню этот ответ с более точными подробностями, как только у меня получится настройка.


Инструменты тестирования:

0
добавлено

Это основная причина, по которой я переключился на Google Web Toolkit ... Я разрабатываю и тестирую на Java и имею разумное ожидание того, что скомпилированный JavaScript будет корректно работать в различных браузерах. Поскольку TDD - это прежде всего функция единичного тестирования, большая часть проекта может быть разработана и протестирована перед компиляцией и развертыванием.

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

0
добавлено

Я никогда не использовал код TDDed UI. Самое близкое, что мы пришли, действительно заключалось в том, чтобы как можно больше отделить UI-код от логики приложения. Это одна из причин, по которой полезен шаблон модели-представления-контроллера - модель и контроллер могут быть TDDed без особых проблем и без слишком усложнения.

По моему опыту, представление всегда оставалось для наших пользовательских приемочных тестов (мы написали веб-приложения, а наши UAT использовали HttpUnit Java). Тем не менее, на этом уровне это действительно интеграционный тест, без свойства тестовой изоляции, которое мы желаем с TDD. Из-за этой настройки нам пришлось сначала написать наш контрольный/модельный тест/код, затем пользовательский интерфейс и соответствующий UAT. Однако в коде Swing GUI, который я писал в последнее время, я сначала писал код GUI с заглушками, чтобы изучить мой дизайн переднего конца, прежде чем добавлять в контроллер/модель/API. YMMV здесь.

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

0
добавлено

В прошлом я делал TDD с Javascript, и мне нужно было различать тесты Unit и Integration. Selenium проверит ваш общий сайт, с выходом с сервера, его обратной почтой, ajax-звонками, и все это. Но для модульного тестирования ничто из этого не важно.

То, что вы хотите, это просто интерфейс, с которым вы будете взаимодействовать, и ваш сценарий. Инструмент, который вы будете использовать для этого, в основном JsUnit , который принимает HTML-документ с некоторыми функциями Javascript на странице и выполняет их в контексте страницы. Итак, что вы будете делать, это включает в себя вычеркнуть HTML на странице с вашими функциями. Оттуда вы можете протестировать взаимодействие вашего скрипта с компонентами пользовательского интерфейса в изолированном блоке издевающегося HTML, вашего сценария и ваших тестов.

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

<�Сильный> tests.html

<html>
<head>
<script src="jsunit.js"></script>
<script src="mootools.js"></script>
<script src="yourcontrol.js"></script>
</head>
<body>
    
  • red
  • green
   
</body>
<script>
    function testListColor() {
        assertNotEqual( $$("#mockList li")[0].getStyle("background-color", "red") );

        var colorInst = new ColorCtrl( "mockList" );

        assertEqual( $$("#mockList li")[0].getStyle("background-color", "red") );
    }
</script>


</html>

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

yourcontrol.js (шаг1)

function ColorCtrl( id ) {
 /* Fail! */    
}

yourcontrol.js (шаг2)

function ColorCtrl( id ) {
    $$("#mockList li").forEach(function(item, index) {
        item.setStyle("backgrond-color", item.getText());
    });
    /* Success! */
}

Вероятно, вы можете увидеть причину боли здесь, вы должны держать ваш макет HTML здесь на странице в синхронизации со структурой того, что будет контролировать ваш сервер. Но это дает вам хорошую систему для TDD с JavaScript.

0
добавлено