1
00:00:06,861 --> 00:00:10,160
- We've been talking a lot
about conversations, examples,

2
00:00:10,160 --> 00:00:13,581
scenarios, but let's get a
better understanding of how that

3
00:00:13,581 --> 00:00:17,870
really fits into our
development lifecycle.

4
00:00:17,870 --> 00:00:21,537
In 2003 Brian Merrick
introduced the idea of

5
00:00:22,961 --> 00:00:27,947
example-driven development,
guiding coding with business

6
00:00:27,947 --> 00:00:32,210
facing examples that we can
turn into executable tests.

7
00:00:32,210 --> 00:00:36,254
We now have many variations
on that theme using

8
00:00:36,254 --> 00:00:40,369
concrete examples to
create executable tests.

9
00:00:40,369 --> 00:00:42,507
The first one we'll talk
about today is acceptance

10
00:00:42,507 --> 00:00:45,823
test-driven development, ATDD.

11
00:00:45,823 --> 00:00:49,950
That arose from extreme
programming and the idea of TDD,

12
00:00:49,950 --> 00:00:53,401
test-driven development
and acceptance tests.

13
00:00:53,401 --> 00:00:57,164
We also have BDD, which is
behavioral-driven development

14
00:00:57,164 --> 00:00:59,461
first introduced by Dan North.

15
00:00:59,461 --> 00:01:03,867
It's easy to read language
simplifies coding of tests.

16
00:01:03,867 --> 00:01:08,187
It let's the domain
experts write behaviors.

17
00:01:08,187 --> 00:01:11,430
The last one we'll mention
is specification by example.

18
00:01:11,430 --> 00:01:14,913
Gojko Adzic talks about
specification workshops with

19
00:01:14,913 --> 00:01:18,651
business stakeholders to
design desirable behaviors

20
00:01:18,651 --> 00:01:20,731
and features scope.

21
00:01:20,731 --> 00:01:24,235
All these variations are
about turning those concrete

22
00:01:24,235 --> 00:01:28,402
examples into executable
tests, building in the quality,

23
00:01:29,275 --> 00:01:31,275
knowing what to build.

24
00:01:31,275 --> 00:01:33,835
The value is in the conversation and the

25
00:01:33,835 --> 00:01:36,075
shared understanding.

26
00:01:36,075 --> 00:01:38,168
So let's start with acceptance
test-driven development.

27
00:01:38,168 --> 00:01:40,971
We'll go into a little bit
more detail on all three.

28
00:01:40,971 --> 00:01:43,574
This is the most generic term,
and this is what we'll use

29
00:01:43,574 --> 00:01:45,632
in this course most of the time.

30
00:01:45,632 --> 00:01:47,473
So we start with a feature.

31
00:01:47,473 --> 00:01:50,749
We discuss the rules, the examples.

32
00:01:50,749 --> 00:01:54,234
We slice it into stories,
however you do that.

33
00:01:54,234 --> 00:01:58,971
For each story we talk about
more rules, more examples.

34
00:01:58,971 --> 00:02:01,574
We introduce high level acceptance tests.

35
00:02:01,574 --> 00:02:03,451
We can execute them.

36
00:02:03,451 --> 00:02:06,593
If you note, we've got this fix defects.

37
00:02:06,593 --> 00:02:10,971
Fixing defects at the
beginning of the cycle is

38
00:02:10,971 --> 00:02:13,490
fixing misunderstandings.

39
00:02:13,490 --> 00:02:17,393
They don't cost very much
to fix, so that's where we

40
00:02:17,393 --> 00:02:20,955
encourage and encourage
all of those conversations.

41
00:02:20,955 --> 00:02:23,814
And then we code and we
test and we code and we test

42
00:02:23,814 --> 00:02:26,972
and we deliver our story,
but we deliver the tests

43
00:02:26,972 --> 00:02:30,389
and the code and the automation together.

44
00:02:31,275 --> 00:02:35,073
When we fix defects
after the code is built,

45
00:02:35,073 --> 00:02:37,675
we find those defects when the tests fail,

46
00:02:37,675 --> 00:02:40,591
and they start to cost a little bit more.

47
00:02:40,591 --> 00:02:44,294
We may discover needed changes,
but when those agreed upon

48
00:02:44,294 --> 00:02:47,461
tests pass, the product owner accepts.

49
00:02:48,577 --> 00:02:51,296
With this process the
automated tests are almost

50
00:02:51,296 --> 00:02:52,463
a side effect.

51
00:02:53,713 --> 00:02:56,537
The value is in the discussions,

52
00:02:56,537 --> 00:02:59,471
getting that shared understanding.

53
00:02:59,471 --> 00:03:03,638
BDD, which is from Dan North,
is easy to read syntax, right?

54
00:03:04,574 --> 00:03:06,275
We describe the behaviors.

55
00:03:06,275 --> 00:03:10,814
You see the most often with
a given-when-then syntax.

56
00:03:10,814 --> 00:03:14,814
Given is a precondition, when
is the trigger, the action,

57
00:03:14,814 --> 00:03:16,697
then is the consequence.

58
00:03:16,697 --> 00:03:20,537
We've been doing tests like
that for a very long time.

59
00:03:20,537 --> 00:03:24,704
So using your power of three
you wanna work together to

60
00:03:25,610 --> 00:03:30,297
understand what this means to
define the system behavior.

61
00:03:30,297 --> 00:03:33,598
We want to make sure everybody
understands and encourage

62
00:03:33,598 --> 00:03:35,497
that conversation.

63
00:03:35,497 --> 00:03:39,337
In this example you see
some very specific numbers.

64
00:03:39,337 --> 00:03:41,095
They're specific examples.

65
00:03:41,095 --> 00:03:43,038
Customer has a balance of one dollar.

66
00:03:43,038 --> 00:03:44,595
That's the precondition.

67
00:03:44,595 --> 00:03:47,875
The when is what happens,
what's the trigger?

68
00:03:47,875 --> 00:03:50,835
They deposit five dollars,
and the authorization code

69
00:03:50,835 --> 00:03:52,334
is received.

70
00:03:52,334 --> 00:03:54,333
The then is what we expect.

71
00:03:54,333 --> 00:03:57,534
We expect that the new
balance is six dollars.

72
00:03:57,534 --> 00:04:00,201
So this a example of a BDD test.

73
00:04:01,838 --> 00:04:04,777
Gojko Adzic talks about
specification workshops, business

74
00:04:04,777 --> 00:04:07,017
stakeholders participating.

75
00:04:07,017 --> 00:04:10,294
This pictures a very, very
simplistic view of what

76
00:04:10,294 --> 00:04:13,874
Gojko talks about, but we
try to define the scope of

77
00:04:13,874 --> 00:04:16,675
each feature using the
examples and scenarios,

78
00:04:16,675 --> 00:04:20,656
turning them into executable
tests to guide coding.

79
00:04:20,656 --> 00:04:22,499
Gojko uses a few different words.

80
00:04:22,499 --> 00:04:25,575
He uses executable
specification, providing living

81
00:04:25,575 --> 00:04:26,742
documentation.

82
00:04:27,817 --> 00:04:31,230
The living documentation
is the automation.

83
00:04:31,230 --> 00:04:34,554
So you can use all three and
find the one that expresses

84
00:04:34,554 --> 00:04:38,635
how your team thinks, and use
whichever version you like

85
00:04:38,635 --> 00:04:41,619
just because they all
have the same premise.

86
00:04:41,619 --> 00:04:43,721
We use examples.

87
00:04:43,721 --> 00:04:46,862
This picture is a sticker
that Brian Merrick

88
00:04:46,862 --> 00:04:48,878
had made years ago.

89
00:04:48,878 --> 00:04:51,014
If you notice, I have
one of the few last ones

90
00:04:51,014 --> 00:04:52,718
on my laptop here.

91
00:04:52,718 --> 00:04:54,521
It's one of my favorite stickers.

92
00:04:54,521 --> 00:04:58,019
Concrete examples, we
call them real examples,

93
00:04:58,019 --> 00:05:01,217
are a great way to
communicate using pictures

94
00:05:01,217 --> 00:05:05,755
or sketches or anything to
help get the point across.

95
00:05:05,755 --> 00:05:09,974
Look at what's being done
manually, and maybe you can use

96
00:05:09,974 --> 00:05:14,875
examples from a spreadsheet
with inputs and outputs

97
00:05:14,875 --> 00:05:17,857
from a loan or anything else.

98
00:05:17,857 --> 00:05:21,524
Use examples to help
start the conversation.