Presentation from MS QA Day, March 2010

1. Behavior-Driven
Development
Бибичев Андрей
март 2010 г.

2. GProfile: bibigone
SlideShare: bibigine
GMail: bibigone
Skype: bibigine

3. «Вы любите Unit-тесты,
как люблю их я?»

4. Сказочка

6. MyStack
+ Count : int
+ Push(v : int)
+ Pop() : int
+ Peek() : int

34. Симптоматическое
лечение
Builder-ы / Custom Assert-ы

36. • тестовые методы называются в стиле TestSomeMethod и являют собой
длинную простыню хитросплетений разных сценариев для проверки
работы одного метода;
• значительную часть тестовых методов занимает подготовка и настройка
окружения, так что тяжело понять, что же именно проверяется;
• попытки поместить создание всего окружения в SetUp-методы делают
тестовые классы путанными, а отдельные тестовые методы
зависимыми друг от друга;
• рекомендация держать ровно один Assert на тест не выполняется или
приводит к огромному дублированию кода;
• при изменении требований не так-то легко найти какие тесты нужно
поправить, и даже найдя их, еще нужно сообразить что и как поправить
в длинном витьеватом коде;
• что делать, если у нескольких тестов есть общая часть, - как ее следует
оформить?
• как "правильно" называть тесты, как их группировать в тестовые
классы?
• как соотносятся между собой acceptance-критерии выполнения
требований и набор unit-тестов?

37. FLUENT BUILDER-Ы

41. Их можно объединять в целые
«потемкинские деревни»

44. Главное:
не делать больших «деревень»,
лучше иметь N маленьких

45. CUSTOM ASSERT-Ы

50. Ваша цель -
ЛАКОНИЧНЫЕ ТЕСТЫ
БЕЗ ВЕТВЛЕНИЙ И ЦИКЛОВ

51. BDD
Разработка на основе поведения

52. Итак, еще остались существенные
проблемы:
• MyClass • MyClassTests
– MethodA – TestMethodA
– MethodB – TestMethodB
– MethodC – TestMethodC
+ тестировщики
+ менеджеры

53. MyStack
+ Count : int
+ Push(v : int)
+ Pop() : int
+ Peek() : int

54. Давайте попробуем описать
поведение класса MyStack
• «класс MyStack должен (should):»
– создавать пустой стек
– инициировать исключение при попытке
извлечь элемент из пустого стека
– извлекать последний положенный в него
элемент
– извлекать все положенные в него элементы в
обратном порядке

56. • «класс MyStack должен (should):»
– создавать пустой стек
GIVEN an empty stack ДАН пустой стек
WHEN Count property is asked КОГДА запрашивается Count
THEN it returns zero ТОГДА возвращается 0
– инициировать исключение при попытке извлечь
элемент из пустого стека
GIVEN an empty stack ДАН пустой стек
WHEN Pop() method is called КОГДА вызывается Pop()
THEN exception is raised ТОГДА возникает исключение

57. • «класс MyStack должен (should):»
– извлекать последний положенный в него
элемент
GIVEN an empty stack
and some integer item
WHEN this item is pushed
and Pop() is called
THEN it returns the last item that’s pushed
and it removes item from the stack
and further Pop() call throws exception

59. Экстремально важный шаблон
тестового метода

60. Дано:
арбуз + гиря 1 кг = гиря 6 кг
арбуз = ?
Решение:
x+1=6
x=6–1=5
Ответ: 5 кг

61. Март 2006
Журнал «Better Software»
Статья «Introducing BDD»
Dan North

63. «Test method names should be sentences»
«A simple sentence template keeps test
methods focused. This sentence template –
The class should do something»
«“Behavior” is a more useful word than “test”»
«What’s the next most important thing the
system doesn’t do?»

64. От пользовательских историй
к описанию поведения
• As [role] • Given [initial context]
I want/can [action] When [event/action]
So that [result] Then [ensure some outcomes]
• Как [роль] • Дано [начальный контекст]
Я хочу/могу [действие] Когда [событие/действие]
Так что [результат] Тогда [конкретный результат]

65. Пример: калькулятор
• Как тугой на голову
Я хочу иметь возможность складывать,
вычитать, делить и умножать два числа
Чтобы видеть результат и не считать в уме

66. Пример: калькулятор
• Дан калькулятор и два числа – «2» и «2»
Когда вводим первое число, «плюс», второе
число
Тогда видим результат «4»
• Дан калькулятор и два числа – «123» и «23»
Когда вводим первое число, «минус», второе
число
Тогда видим результат «100»

67. Сценарии
Поведение

68. Новые интересные метрики
• Количество описанных «Поведений»
• Процент автоматизированных тестов на
«Поводение» по отношению к общему
числу описанных «Поведений»
• Отношение количества «Поведений» к
количеству Пользовательских историй или
фич

70. Ноябрь 2009
Конференция «Agile Specifications,
BDD and Testing eXchange»
Dan North
«BDD is a second-generation, outside-in, pull-
based, multiple-stakeholder, multiple-scale, high-
automation, agile methodology. It describes a
cycle of interactions with well- defined outputs,
resulting in the delivery of working, tested
software that matters.»

71. Agile 2.0 ? 

72. Связь с TDD и DDD

73. TEST-DRIVEN DEVELOPMENT

74. Написание Unit-тестов
≠
Test-Driven Development

76. Цикл разработки в TDD
Написание неработающего теста
для новой функциональности
RED
REFACTOR GREEN
Рефакторим код, чтобы Пишем ровно столько кода,
тесты продолжили проходить, чтобы тест прошел
а код стал чистым

77. Традиционный цикл разработки
Пишем сразу заметный
кусок функциональности
CODING
DEBUGING COMPILING
Отлаживаем код, Добиваемся
ловим и исправляем компилируемости
поверхностные баги

78. Написание тестов
с использованием
*Unit-фреймворков
≠
Unit-тестирование
(в строгом смысле)

79. Тестируем как
черный ящик
Тестируем как
прозрачный
ящик Интеграционные
тесты Mock-и,
Stub-ы
Модульные
тесты
(в строгом смысле)

80. Функциональные тесты
Нагрузочные тесты
Стресс-тесты
…

81. BDD – TDD done well?
«I believe this is more than just ‘doing TDD well’.
I think it’s ‘doing TDD and a number of other practices
related to professional software development well’.
The five practices above might
conceivably be done in addition to TDD,
but they’re not part of any definition of TDD I’ve seen.»

82. DOMAIN-DRIVEN DESIGN

83. История
2004 год
Eric Evans
«Domain-Driven Design - Tackling Complexity in the Heart of Software»

84. Domain (словарь)
• наследственная собственность; имение,
поместье; земли; владение e.g. DNS
• территория, зона, область, район
(отмеченные некоторыми физическими
особенностями)
• сфера (интересов), поле (деятельности),
область (знаний) В данном случае
этот смысл
• область определения (мат.)
Домен поля
таблицы в БД

85. Т.е. это о
Business Domain
Предметной области
и
Business Logic
Бизнес-логики

86. Центральная роль в
мышлении,
проектировании,
реализации
DDD

87. Три аспекта DDD

91. • Даны шаг бегунка в исходном состоянии
и текущий пользователь – «Петров»
Когда для этого шага выполняется действие
«Подтвердить»
Тогда сам шаг переходит в состояние «+»
и автором подтверждения помечается
«Петров»

92. • Даны шаг бегунка в состоянии «?»
и в бегунке есть следующий шаг в исходном
состоянии
и текущий пользователь – «Петров»
Когда для этого шага выполняется действие
«Подтвердить»
Тогда сам шаг переходит в состояние «+»
и автором подтверждения помечается
«Петров»
и следующий шаг бегунка переходит в
состояние «?»

94. ИТОГО ПО *DD

95. Синергетический
эффект 
DDD
TDD BDD

96. Фреймворки

97. SpecUnit.Net

99. MSpec

101. NBehave

103. SubSpec for xUnit.Net

105. Своими руками

109. Заключение

110. vs.
[TestMethod] [TestMethod]
void Test…() void Should…()
{ {
// Arrange // GIVEN
… …
// Action // WHEN
… …
// Assertion // THEN
… …
} }

111. Гипотеза
лингвистической относительности
• aka «гипотеза Сепира-Уорфа»
• существующие в сознании человека
системы понятий, а, следовательно, и
существенные особенности его мышления
определяются тем конкретным языком,
носителем которого этот человек является

112. GUI
Модель
Поведение модели
Аналитик
Тестировщик Разработчик

113. Спасибо за
внимание!
biBIGone@gmail.com
http://www.google.com/profiles/biBIGone