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

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

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

Ответы

Ответ 1

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

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

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

tests.html

<html>
<head>
<script src="jsunit.js"></script>
<script src="mootools.js"></script>
<script src="yourcontrol.js"></script>
</head>
<body>
    <ul id="mockList">
        <li>red</li>
        <li>green</li>
    </ul>   
</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(step1)

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'ing с JavaScript.

Ответ 2

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

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

Настройка не требуется. Он просто работает.

http://github.com/davidjnelson/agilejs