1
00:00:04,773 --> 00:00:06,060
In today's lesson,

2
00:00:06,085 --> 00:00:10,776
we'll be exploring one way
in which tests can be classified.

3
00:00:10,973 --> 00:00:15,857
There are many ways one can go
about in classifying their tests,

4
00:00:15,967 --> 00:00:20,343
but a very common classification
used in the industry

5
00:00:20,368 --> 00:00:25,933
revolves around three main types
of tests based on their scopes.

6
00:00:26,313 --> 00:00:33,300
These are the unit tests, feature tests,
and finally, E2E tests.

7
00:00:34,166 --> 00:00:37,433
Let's discuss
these different types of tests

8
00:00:37,500 --> 00:00:41,933
and their respective purposes
in the test hierarchy.

9
00:00:43,043 --> 00:00:48,683
Unit tests, as the name implies,
focus on individual units of code.

10
00:00:49,133 --> 00:00:55,000
For example, individual functions,
methods, and, in the case of Vue projects,

11
00:00:55,033 --> 00:00:59,933
even simpler support components
are tested under unit tests.

12
00:01:00,208 --> 00:01:02,174
When a unit test fails,

13
00:01:02,199 --> 00:01:07,500
the developer will know precisely
the problematic point in the code base.

14
00:01:08,997 --> 00:01:13,300
Going a little higher,
we get to the feature tests.

15
00:01:13,652 --> 00:01:18,500
We are no longer talking about
individual units of code by themselves,

16
00:01:18,533 --> 00:01:24,267
but rather a specific feature
that we want the application to fulfill.

17
00:01:25,026 --> 00:01:29,833
Their execution will result
in multiple elements of the application

18
00:01:29,867 --> 00:01:31,667
interacting with each other.

19
00:01:32,133 --> 00:01:36,867
These tests are still aware
of some implementation details,

20
00:01:36,940 --> 00:01:39,267
but not as much as unit tests.

21
00:01:40,000 --> 00:01:43,567
For example, even at a feature test level,

22
00:01:43,567 --> 00:01:49,200
our tests will make specific
invocations tailored for Vue.js

23
00:01:49,493 --> 00:01:51,533
through Vue Test Utils.

24
00:01:52,976 --> 00:01:54,767
If a feature test fails,

25
00:01:54,800 --> 00:01:58,300
the feedback will not
necessarily point precisely

26
00:01:58,325 --> 00:02:00,533
to the problematic piece of code,

27
00:02:00,826 --> 00:02:04,300
but still very little
investigation should be needed,

28
00:02:04,380 --> 00:02:08,533
because the scope of the tests
is still somewhat limited.

29
00:02:09,267 --> 00:02:12,300
Finally, we have E2E tests.

30
00:02:12,820 --> 00:02:16,467
At this level,
we're testing the application as a whole,

31
00:02:16,533 --> 00:02:20,433
in a full simulation
of end-user interactions.

32
00:02:21,127 --> 00:02:22,716
This is the type of test

33
00:02:22,741 --> 00:02:26,833
that is at the highest level
from all three we've covered today.

34
00:02:27,533 --> 00:02:30,833
Just like your end-user will not know

35
00:02:30,900 --> 00:02:34,526
that your website
is running in Vue TypeScript,

36
00:02:34,659 --> 00:02:39,167
your E2E tests
also do not need to know that.

37
00:02:39,433 --> 00:02:43,233
For that reason, from all
the three tests that we have covered,

38
00:02:43,266 --> 00:02:45,333
this is the one that knows the least

39
00:02:45,367 --> 00:02:48,633
about the implementation
of your application.

40
00:02:49,500 --> 00:02:52,300
Since these are running
at the highest level,

41
00:02:52,333 --> 00:02:56,367
if an E2E test fails,
the reason behind the failure

42
00:02:56,400 --> 00:02:59,700
could be at many different places
throughout the app.

43
00:03:00,100 --> 00:03:03,756
For that reason, a longer investigation
might be necessary

44
00:03:03,781 --> 00:03:05,400
by the development team.

45
00:03:06,193 --> 00:03:10,033
Each type of test is valuable
and serves a purpose.

46
00:03:10,319 --> 00:03:12,230
I think a great way for us

47
00:03:12,255 --> 00:03:16,633
to understand where each of these types
of tests falls in line

48
00:03:16,658 --> 00:03:18,933
is by seeing them in practice.

49
00:03:19,433 --> 00:03:23,633
I have put together
a small weight converter calculator.

50
00:03:23,900 --> 00:03:27,633
It's meant to convert
between kilograms and pounds.

51
00:03:28,067 --> 00:03:33,167
For example,
I can turn 100 kilograms into pounds,

52
00:03:33,760 --> 00:03:39,467
and I can also convert
100 pounds into kilograms.

53
00:03:41,443 --> 00:03:44,600
As you may be able to see
in this test suite over here,

54
00:03:44,633 --> 00:03:48,967
I decided that one way for me
to handle these weight conversions

55
00:03:49,000 --> 00:03:53,633
would be to use a data object
to represent the weight.

56
00:03:55,197 --> 00:03:59,033
This data object
is just a plain TypeScript class.

57
00:04:00,133 --> 00:04:03,133
But what I want you to focus on, however,

58
00:04:04,243 --> 00:04:06,633
are the unit tests that I wrote here.

59
00:04:08,083 --> 00:04:11,697
For example, I wrote a test
that would prove to me

60
00:04:11,722 --> 00:04:15,433
that I can convert
from pounds to kilograms,

61
00:04:15,860 --> 00:04:17,733
and I also wrote another test

62
00:04:17,767 --> 00:04:21,133
that I could provide
a specific weight in kilograms,

63
00:04:21,207 --> 00:04:26,867
and I hope to get the properly
converted weight in pounds.

64
00:04:28,497 --> 00:04:33,733
These tests here are just for this
data object operating by itself.

65
00:04:34,367 --> 00:04:36,200
I'm giving it some values

66
00:04:36,225 --> 00:04:40,933
and requesting it to give me
back as another unit of weight

67
00:04:41,100 --> 00:04:44,133
and asserting that I'm getting
the expected value back.

68
00:04:45,606 --> 00:04:47,659
At a bit of a higher level now,

69
00:04:48,033 --> 00:04:53,033
we can look into the feature tests
that I wrote for the vue component.

70
00:04:53,432 --> 00:04:55,700
Notice that at this point,

71
00:04:55,740 --> 00:04:57,767
I'm mounting the vue component

72
00:04:57,792 --> 00:05:00,800
and interacting
with the different controls

73
00:05:00,833 --> 00:05:03,200
that are being rendered to the page.

74
00:05:04,093 --> 00:05:05,896
So for example, over here,

75
00:05:05,921 --> 00:05:10,467
I am typing into the weight input
the value of 100,

76
00:05:10,492 --> 00:05:14,000
and I'm checking the pounds checkbox.

77
00:05:14,233 --> 00:05:17,700
And then I'm hoping
to get a specific value back,

78
00:05:18,133 --> 00:05:20,433
in the input element for the weight.

79
00:05:21,677 --> 00:05:26,033
This test does not know
how I'm doing the conversion itself,

80
00:05:26,100 --> 00:05:27,567
and this is good.

81
00:05:28,459 --> 00:05:33,633
The test should know as little as possible
about the implementation details.

82
00:05:34,479 --> 00:05:36,875
I classify these as feature tests

83
00:05:36,900 --> 00:05:40,500
because they are describing
specific features

84
00:05:40,567 --> 00:05:42,633
that the application needs to fulfill.

85
00:05:43,667 --> 00:05:48,463
However, please note
that part of the Vue.js community

86
00:05:48,488 --> 00:05:52,267
would still be classifying
these tests as unit tests.

87
00:05:52,579 --> 00:05:54,442
And from that perspective,

88
00:05:54,467 --> 00:05:58,867
it's because this is testing
a vue component in isolation.

89
00:05:59,867 --> 00:06:03,667
I tend not to get
too worried about semantics.

90
00:06:03,933 --> 00:06:07,900
All I hope here
is that we can understand the idea

91
00:06:07,933 --> 00:06:10,533
behind what I'm calling the feature tests.

92
00:06:12,046 --> 00:06:17,933
Finally, I also want to show
some E2E tests that I have written.

93
00:06:18,300 --> 00:06:19,900
Notice that here,

94
00:06:19,967 --> 00:06:24,467
I'm also testing specific
user stories for my application.

95
00:06:24,667 --> 00:06:30,233
But now, the test doesn't even know
what front-end framework we're using.

96
00:06:30,866 --> 00:06:33,070
As you can see here, to run these tests,

97
00:06:33,095 --> 00:06:36,933
we are starting a local server
and opening a browser.

98
00:06:38,457 --> 00:06:43,575
And in here, we are visiting
a real page in our application

99
00:06:43,600 --> 00:06:46,663
and programmatically
interacting with the page

100
00:06:46,688 --> 00:06:48,467
like a real person would do.

101
00:06:49,579 --> 00:06:53,533
For example, right here,
I am visiting the page,

102
00:06:54,200 --> 00:06:58,433
I am going to the input for the weight,

103
00:06:58,567 --> 00:07:01,467
I'm clearing the input, typing 75,

104
00:07:01,933 --> 00:07:05,900
and then I'm selecting the pounds button
and clicking on it.

105
00:07:06,367 --> 00:07:13,133
Finally, I'm verifying that I have
the weight of 165.35 pounds

106
00:07:13,433 --> 00:07:14,633
in my input.

107
00:07:15,600 --> 00:07:18,633
Of the three types of tests
we have covered today,

108
00:07:18,733 --> 00:07:23,500
this is the slowest
and most resource-intensive of them.

109
00:07:23,933 --> 00:07:25,803
But it shines on the ground

110
00:07:25,828 --> 00:07:31,333
that it's closest to what the user
will truly be experiencing.

111
00:07:33,290 --> 00:07:37,933
TDD can technically be used
with any of these levels,

112
00:07:38,133 --> 00:07:43,067
but my preferred pattern is to drive
the behavior of the application first

113
00:07:43,167 --> 00:07:44,697
through feature tests.

114
00:07:45,033 --> 00:07:49,933
Any helper resources that prove
to be needed over the development flow

115
00:07:49,958 --> 00:07:53,600
can have their implementation
driven through unit tests.

116
00:07:53,867 --> 00:07:57,133
Finally, E2E tests are great

117
00:07:57,158 --> 00:07:59,933
for protecting
the most important user stories

118
00:07:59,967 --> 00:08:02,833
once the feature tests
are already in place.

119
00:08:04,663 --> 00:08:06,408
My reasoning behind this

120
00:08:06,433 --> 00:08:10,233
is that feature tests
are in this sweet spot

121
00:08:10,400 --> 00:08:11,803
where you can write tests

122
00:08:11,833 --> 00:08:17,333
that guard user stories without enforcing
specific implementation strategies.

123
00:08:17,833 --> 00:08:21,367
They are also relatively fast
to run and write,

124
00:08:21,533 --> 00:08:25,257
and in case of failures,
they still provide feedback

125
00:08:25,300 --> 00:08:28,401
that can be specific enough
for the development team

126
00:08:28,426 --> 00:08:32,133
to understand what is the cause
of the regression very quickly.

127
00:08:33,360 --> 00:08:38,697
Great! Now you know the differences
between unit, feature, and E2E tests.