Модульные тесты по сравнению с Функциональными испытаниями
Когда вы вызываете element.innerHTML = "something", вы перезаписываете значение, которое в данный момент находится в этом элементе. Смотрите эту демонстрацию:
document.getElementById("foo").addEventListener("click", function() {
document.getElementById("text").innerHTML = "foo";
});
document.getElementById("bar").addEventListener("click", function() {
document.getElementById("text").innerHTML = "bar";
});This will be completely overwritten
Итак, когда вы делаете
document.getElementById('pokaz').innerHTML = "b";
document.getElementById('pokaz').innerHTML = "b";
, вы сначала создаете элемент с идентификатором kwotyPierwsze, затем вы перезаписываете его элементом с идентификатором kwotyDrugie. Первая пропала, поэтому следующая строка
document.getElementById('kwotyPierwsze').innerHTML = "";
не может найти идентификатор kwotyPierwsze и не удается .
Вам нужно добавлять свои элементы, не перезаписывая их - либо добавляя их в разные контейнеры, либо добавляя оба, а не просто один за другим
Например, вы можете просто сделать это
document.getElementById('pokaz').innerHTML = "b" +
"b";
[ 1121] Вам не нужен +, но он делает его немного более читабельным, потому что там есть два элемента.
6 ответов
Модульное тестирование - тестирование отдельного модуля, такого как метод (функция) в классе, с моделированием всех зависимостей.
Функциональный тест - тест интеграции AKA, тестирующий часть функциональности в системе. Это позволит протестировать многие методы и может взаимодействовать с зависимостями, такими как базы данных или веб-службы.
очень просто мы можем сказать:
- черный квадрат: тест пользовательского интерфейса как функциональное испытание
- белое поле: кодируйте тест как модульный тест
, читает больше здесь .
Модульный тест проверяет независимую единицу поведения . Что такое единица поведения? Это самая маленькая часть системы, которая может быть протестирована отдельно. (Это определение на самом деле круглое, IOW это вообще не определение , но, похоже, оно работает довольно хорошо на практике, потому что вы можете вроде бы понять его интуитивно.)
Функциональные тесты тестов независимая часть функциональности.
Единица поведения очень мала: хотя мне абсолютно не нравится эта дурацкая мантра «один единичный тест на метод», с точки зрения размера она примерно правильная. Единица поведения - это что-то среднее между частью метода и, возможно, парой методов. В лучшем случае объект, но не более одного.
Часть функциональности обычно включает в себя множество методов и разрезает несколько объектов, а часто и несколько архитектурных уровней.
Модульный тест будет выглядеть примерно так: когда я вызываю функцию
validate_country_code ()и передаю ей код страны'ZZ', она должна возвращатьfalse.Функциональная проверка: когда я заполняю форму доставки с кодом страны
ZZ, я должен быть перенаправлен на страницу справки, которая позволяет мне выбрать код страны из меню.
Модульные тесты пишутся разработчиками для разработчиков с точки зрения разработчика.
Функциональные тесты могут быть доступны пользователю, и в этом случае они написаны разработчиками вместе с пользователями (или, возможно, с помощью правильных инструментов и правильных пользователей, даже самими пользователями), для пользователей, с точки зрения пользователя. Или они могут быть обращены к разработчику (например, когда они описывают некоторую внутреннюю часть функциональности, которая не волнует пользователя), и в этом случае они написаны разработчиками для разработчиков, но все же с точки зрения пользователя.
В первом случае функциональные тесты могут также служить приемочными тестами и исполняемым кодированием функциональных требований или функциональной спецификации, во втором случае они также могут служить интеграционными тестами.
Модульные тесты часто меняются, функциональные тесты никогда не должны меняться в основной версии.
Я думаю об этом так: модульный тест устанавливает, что код выполняет то, что вы хотели от кода (например, вы хотели добавить параметр a и b, вы фактически добавляете их, а не вычитаете), функциональные тесты проверяют, что весь код работает вместе, чтобы получить правильный результат, так что то, что вы намеревались сделать, на самом деле дает правильный результат в система.
Юнит-тесты говорят разработчику, что код делает вещи правильно; функциональные тесты говорят разработчику, что код делает правильные вещи.
Вы можете прочитать больше на Unit Testing versus Functional Testing
Хорошо объясненная реальная аналогия unit testing и functional testing может быть описана следующим образом,
Много раз разработку системы сравнивают со строительством дома. Хотя эта аналогия не совсем корректна, мы можем расширить ее для целей понимания разницы между модульным и функциональным тестированием.
Юнит-тестирование можно сравнить с инспектором, посещающим строительную площадку дома. Его внимание сосредоточено на различных внутренних системах дома, фундаменте, каркасе, электрике, водопроводе и так далее. Он гарантирует (тестирует), что части дома будут работать правильно и безопасно, то есть соответствовать строительным нормам.
Функциональные тесты в этом сценарии аналогичны посещению домовладельцем этой же строительной площадки. Он предполагает, что внутренние системы будут вести себя надлежащим образом, что строительный инспектор выполняет свою задачу. Владелец дома сосредоточен на том, каково будет жить в этом доме. Его волнует, как выглядит дом, удобного ли размера различные комнаты, соответствует ли дом потребностям семьи, хорошо ли расположены окна, чтобы ловить утреннее солнце.
Владелец дома проводит функциональные испытания дома. У него есть точка зрения пользователя.
Строительный инспектор выполняет модульные тесты дома. Он имеет точку зрения строителя.
В качестве резюме:
Юнит-тесты пишутся с точки зрения программиста. Они создаются для того, чтобы убедиться, что определенный метод (или единица) класса выполняет набор определенных задач.
Функциональные тесты пишутся с точки зрения пользователя. Они гарантируют, что система функционирует так, как ожидают пользователи.
"Функциональный тест" не означает, что вы тестируете функцию (метод) в вашем коде. Обычно это означает, что вы тестируете функциональность системы - когда я запускаю foo file.txt в командной строке, строки в file.txt становятся обратными, возможно. Напротив, один модульный тест обычно охватывает один случай одного метода -- length("hello") должен вернуть 5, а length("hi") должен вернуть 2.
См. также Взгляд IBM на границу между модульным и функциональным тестированием.