На курсах TDD обычно избегают написания спецификаций — утверждений или проверочных гипотез — поскольку здесь мало программирования.
Однако они очень важны.
Они определяют, как и какие тесты будут написаны, а также определяют, насколько легко будет исправить поломку.
Для их реализации практически не требуется времени.
Это первое, что связывает пользовательскую историю и код, и первое, что показывает провал тестового кода.
Они же являются тем, что дополнительно защищает нас от ошибок в коде самого теста.
Как мы могли бы улучшить наши заявления? Во-первых, спецификации должны относиться к пользовательской истории с точки зрения .
Если пользователь истории использует термин «вход», то утверждения не могут изменить этот термин на аутентификацию/авторизацию/проверку.
Если история написана плохо, измените ее.
Во-вторых, спецификация должна явно содержать название компонента который они описывают. Это указывает на область тестирования и сигнализирует об ошибке, если в область часто входят неожиданные компоненты.
Валидный скрипт хорошо соответствует принципу единой ответственности, поэтому имя компонента должно совпадать с описанием теста.
Если валидных скриптов много, то, вероятно, на компоненте лежит слишком большая ответственность.
Также один сценарий, как правило, описывает либо событие ui, либо какой-то паттерн.
Хорошие кандидаты на имя компонента могут содержать имя паттерна: Validator, Strategy, Builder, Transformer, Controller и т.д. Или название события: Submitter, Login, ReadonlyOrderView и т.д. Т.
е.
В зависимости от названия компонента должны быть определены как входные, так и выходные значения основной функции класса.
Плохие имена: слишком абстрактные (Service, Component, Helper, Utility) и двойные (ValidatorAndRenderer).
Третий, спецификации должны явно указывать условия .
Плохо:
Лучше:@Test public void testValidatePassword(){}
@Test public void loginController_whenValidUsername_andValidPassword_shouldLogUserIn(){}
Нам не придется вызывать эту функцию откуда-то еще, поэтому допустимы сверхдлинные имена.
Если количество условий в тесте не умещается в строку, то, возможно, следует изменить структуру компонента.
То же самое и с javascript-тестами, но туда можно вкладывать условия, что делает его более удобным.
describe('login UI component', () => {
describe('when username provided', () => {
describe('when valid password', () => {
it('should log user in', () => {
.
});
});
});
});
Явные термины легче читать и найти пропавшие .
Кроме того, если условие не соответствует написанному тестовому коду, то код можно легко исправить.
Хорошее описание, в общем, является заменой документации и комментариев кода.
Он абстрактен, не зависит от фреймворка и компилятора, и его следует воспринимать с той же серьезностью, что и последние два.
Сами условия должны быть согласованы в коде для удобства чтения, например ДАННО-КОГДА-ТО-СЛЕДУЕТ и т. д. В-четвертых, спецификации должны быть упрощены .
Полезно записать их в обратном порядке: Сначала ошибки, сначала нули, потом счастливый путь.
Тогда нет желания заканчивать тестирование после одного валидного варианта использования.
Для компонентов пользовательского интерфейса: рендеринг, события.
Для компонентов с состоянием все состояния являются последовательными.
Таким образом, структура хорошо читаемой спецификации выглядит так: 5-10 ошибок, один валидный скрипт (или несколько вариантов одного и того же скрипта).
Хорошая практика при написании спецификации — написать ее полностью в виде текста, а затем попросить коллегу прочитать ее для ясности и отсутствия недостающих терминов.
Тогда, собственно, и можно приступать к написанию реализации.
Довольно часто уже в таком виде задача отчуждается, т.е.
хорошо, когда реализацию тестов пишет кто-то другой.
В-пятых, реализация теста должна соответствовать тому, что написано в описании .
Хорошей практикой является разделение его на Arrange-Act-Assert, чтобы легко сопоставить ту или иную часть реализации.
Текст утверждений и исключений, если они присутствуют, также должен быть соотнесен с описаниями тестов; как правило, мы можем их просто дублировать.
Само собой разумеется, что при добавлении условий или утверждений в тест вам также необходимо обновить описания тестов.
Итак, последовательность написания спецификации может быть следующей.
- прочитать историю пользователя
- назовите компонент и действительный скрипт
- сформулировать условия валидного сценария
- дополнить спецификацию ошибочными сценариями, разместив их вверху
- пусть сосед прочитает и исправит то, что он пропустил
- Реализуйте тесты и компоненты один за другим, используя цикл рефакторинга «красный-зеленый».
-
Nist Принимает Стандарт Безопасности Bios
19 Oct, 24 -
Форекс – Это Не Гербалайф?
19 Oct, 24
