Маркус Гэртнер. ATDD. Разработка программного обеспечения через приемочные тесты.
Книжка тонкая, больше половины (146 страниц из 210) - примеры, информативность... некоторая есть.
Но какой перевод! Сказка, а не перевод. Корректный, с фамилиями в скобках, литературный...
Издательство - ДМК, перевел Слинкин А.А. Его переводы можно брать и на русском, что приятно радует.
О книжке.
ATDD - это Acceptance Test-Driven Development.
Очередной Agile.
Собираются заказчик, программист, тестировщик и обсуждают, что, собственно, нужно. Вырабатывают спецификации, которые должны быть понятными и удобными.
Большие тексты Маркус не одобряет, ибо их мало кто читает.
Обсуждать стараются не в общем, а конкретно, с созданием примеров - это что-то вроде user-story, но не совсем.
Маркус предлагает, как можно оформить примеры:
- BDD, то есть "разработка на основе поведения", каждое требование формируется из трех частей: given-when-then. When желательно делать короткий, в одно действие.
- Табличные форматы:
- - - Решений - это когда колонки "на входе подаем Х" - "на выходе ожидаем У"
- - - Переходов - это возможные варианты "куда я могу идти из состояния, скажем, "Ла"
- - - запросов и скриптов, но я не очень понял, как их юзать для спецификаций.
- автоматизацией могут управлять ключевые слова, но этот метод сейчас плохо заимплеменчен, ждем светлое будущее.
Собирать желательно как минимум троих - от заказчиков (они знают бизнес-правила), от программистов (они знают, как это кодить), и или БА или тестер как посредник. Тестер даже лучше - он знает, как тестировать. Я бы сказал - тогда уж лучше четыре, с тестером.
Встречи желательно планировать и не тратить впустую время заказчика.
Если встречи частые - можно обсуждать каждую фичу, но быстро.
Если короткие - то тут уж как заказчик согласится. Если все равно быстро, придется вертеться.
"Сбор требований" - не очень хороший термин, "траление требований" автору нравится больше. Потому как требования не лежат на поверхности, их ловить надо.
После встречи тестер пишет каркас автотестов - есть программы, которые позволяют писать автотесты на языке, близком к английскому (Cucumber) или даже в системе Вики (FitNesse).
Писать их желательно дружелюбно, то есть так, чтобы даже заказчик мог понять, что, собственно, происходит.
Правда, каркасу требуется вспомогательный код, чтобы прогонять эти автотесты на непосредственно коде. Вот тут важно взаимодействие с программистом - чтоб программист помог написать этот самый вспомогательный код.
Надо выбрать такой вспомогательный код, который будет удобен и понятен всем. И в настоящем, и, что важно - в будущем тоже.
Тут много слов про важность взаимодействия тестера и программиста. Как по мне - тут еще показано, что тестер тоже должен уметь "пасти котов", но прямо про это не пишут.
По ходу написания каркаса и вспомогательного кода могут вылезти некоторые моменты, которые повлияют на собственно сам код - уточнят задачу или реализацию.
Автотесты на основе user-story - это хорошо, но если по ней пройтись стандартными qa-методиками (классами эквивалентности, граничные значения, комбинаторный подход).
Но!
После этого тестов станет много. Очень много. Автотесты, которые выполняются дольше 10 минут запускаются не каждый раз. Автотесты, которые прогоняются дольше нескольких часов - это совсем плохо, слишком долго приходится ждать ответ.
Приходится ужимать и сокращать.
Ну или хотя бы выделить "быстрый блок", а потом запускать "долгий".
Но тут возникает еще одно "но":
Автотесты не могут покрыть и проверить все. Нужны и мануальщики, которые будут проходить большее число тестов, и будут проводить исследовательское тестирование, и т.п.
И к созданию автотестов надо подходить, как к программированию.
То есть, желательно делать итерации - сделали что-то простое, проверили. Бегает - хорошо, сохранили, навернули сверху пару проверок. Бегает? Хорошо, навернули еще.
Проверили - все ли хорошо с кодом или требуется рефакторинг. Если требуется, переделали и пошли дальше.
Рефакторинг нужен на всех стадиях: если автотесты в каркасе слишком сложные - надо переделывать.
Если вспомогательный код слишком сложный - тоже надо переделывать, и нельзя откладывать на потом, потом времени не будет. Даже если есть желание переделать старый автотест - нельзя противиться таким желаниям, надо переписывать.
Как-то так.
В общем и целом понятно, применимо ли на практике - тут пробовать надо.
Но какой перевод! Сказка, а не перевод. Корректный, с фамилиями в скобках, литературный...
Издательство - ДМК, перевел Слинкин А.А. Его переводы можно брать и на русском, что приятно радует.
О книжке.
ATDD - это Acceptance Test-Driven Development.
Очередной Agile.
Собираются заказчик, программист, тестировщик и обсуждают, что, собственно, нужно. Вырабатывают спецификации, которые должны быть понятными и удобными.
Большие тексты Маркус не одобряет, ибо их мало кто читает.
Обсуждать стараются не в общем, а конкретно, с созданием примеров - это что-то вроде user-story, но не совсем.
Маркус предлагает, как можно оформить примеры:
- BDD, то есть "разработка на основе поведения", каждое требование формируется из трех частей: given-when-then. When желательно делать короткий, в одно действие.
- Табличные форматы:
- - - Решений - это когда колонки "на входе подаем Х" - "на выходе ожидаем У"
- - - Переходов - это возможные варианты "куда я могу идти из состояния, скажем, "Ла"
- - - запросов и скриптов, но я не очень понял, как их юзать для спецификаций.
- автоматизацией могут управлять ключевые слова, но этот метод сейчас плохо заимплеменчен, ждем светлое будущее.
Собирать желательно как минимум троих - от заказчиков (они знают бизнес-правила), от программистов (они знают, как это кодить), и или БА или тестер как посредник. Тестер даже лучше - он знает, как тестировать. Я бы сказал - тогда уж лучше четыре, с тестером.
Встречи желательно планировать и не тратить впустую время заказчика.
Если встречи частые - можно обсуждать каждую фичу, но быстро.
Если короткие - то тут уж как заказчик согласится. Если все равно быстро, придется вертеться.
"Сбор требований" - не очень хороший термин, "траление требований" автору нравится больше. Потому как требования не лежат на поверхности, их ловить надо.
После встречи тестер пишет каркас автотестов - есть программы, которые позволяют писать автотесты на языке, близком к английскому (Cucumber) или даже в системе Вики (FitNesse).
Писать их желательно дружелюбно, то есть так, чтобы даже заказчик мог понять, что, собственно, происходит.
Правда, каркасу требуется вспомогательный код, чтобы прогонять эти автотесты на непосредственно коде. Вот тут важно взаимодействие с программистом - чтоб программист помог написать этот самый вспомогательный код.
Надо выбрать такой вспомогательный код, который будет удобен и понятен всем. И в настоящем, и, что важно - в будущем тоже.
Тут много слов про важность взаимодействия тестера и программиста. Как по мне - тут еще показано, что тестер тоже должен уметь "пасти котов", но прямо про это не пишут.
По ходу написания каркаса и вспомогательного кода могут вылезти некоторые моменты, которые повлияют на собственно сам код - уточнят задачу или реализацию.
Автотесты на основе user-story - это хорошо, но если по ней пройтись стандартными qa-методиками (классами эквивалентности, граничные значения, комбинаторный подход).
Но!
После этого тестов станет много. Очень много. Автотесты, которые выполняются дольше 10 минут запускаются не каждый раз. Автотесты, которые прогоняются дольше нескольких часов - это совсем плохо, слишком долго приходится ждать ответ.
Приходится ужимать и сокращать.
Ну или хотя бы выделить "быстрый блок", а потом запускать "долгий".
Но тут возникает еще одно "но":
Автотесты не могут покрыть и проверить все. Нужны и мануальщики, которые будут проходить большее число тестов, и будут проводить исследовательское тестирование, и т.п.
И к созданию автотестов надо подходить, как к программированию.
То есть, желательно делать итерации - сделали что-то простое, проверили. Бегает - хорошо, сохранили, навернули сверху пару проверок. Бегает? Хорошо, навернули еще.
Проверили - все ли хорошо с кодом или требуется рефакторинг. Если требуется, переделали и пошли дальше.
Рефакторинг нужен на всех стадиях: если автотесты в каркасе слишком сложные - надо переделывать.
Если вспомогательный код слишком сложный - тоже надо переделывать, и нельзя откладывать на потом, потом времени не будет. Даже если есть желание переделать старый автотест - нельзя противиться таким желаниям, надо переписывать.
Как-то так.
В общем и целом понятно, применимо ли на практике - тут пробовать надо.