Разработка пользовательского интерфейса на JavaScript с использованием принципов TDD - PullRequest
43 голосов
/ 18 сентября 2008

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

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

Ответы [ 7 ]

22 голосов
/ 19 сентября 2008

В прошлом я работал с TDD с Javascript, и мне нужно было провести различие между модульными и интеграционными тестами. 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>
    <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 (step2)

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

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

4 голосов
/ 19 сентября 2008

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

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

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

2 голосов
/ 01 декабря 2008
1 голос
/ 22 апреля 2009

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

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

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

0 голосов
/ 16 февраля 2013

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

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

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

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

http://github.com/davidjnelson/agilejs

0 голосов
/ 19 сентября 2008

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

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

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

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


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

0 голосов
/ 18 сентября 2008

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...