-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
121 lines (103 loc) · 6 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Test Driven Development</title>
<link type="text/css" href="style.css" rel="stylesheet"></link>
<link type="text/css" href="slide.css" rel="stylesheet"></link>
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
<script type="text/javascript" src="slide.js"></script>
</head>
<body>
<h1 id="title" class="slide">TDD</h1>
<p class="tagline">My thoughts on Test Driven Development</p>
<h2 id="definition" class="slide">definition</h2>
<ul class="list">
<li>tests are small examples of how things should work</li>
<li>ideally one test checks single requirement</li>
<li>test -> <font color="red">red</font> -> implementation -> <font color="green">green</font></li>
<li>refactor?</li>
</ul>
<h2 id="why" class="content slide">why?</h2>
<h3 id="why-1" class="content slide"></h3>
<ul class="list">
<li>no developer is able to keep all requirements in memory</li>
<li>eventually bugs will slip into the code</li>
<li>test won’t fail without reason</li>
</ul>
<h3 id="why-2" class="content slide"></h3>
<ul class="list">
<li>stability of the system</li>
<li>sleep well at night</li>
<li>confidence</li>
</ul>
<h3 id="why-3" class="content slide"></h3>
<ul class="list">
<li>no pain refactoring, especially when changing implementation of some critical service</li>
<li>quick feedback loop</li>
<li>no deployments and manual clicking needed to add new features</li>
</ul>
<h3 id="why-4" class="content slide"></h3>
<ul class="list">
<li>testable code is usually more clean and better structured</li>
<li>legacy code = not tested code in my book, noone like rewriting legacy stuff so...</li>
</ul>
<h3 id="why-5" class="content slide"></h3>
<ul class="list">
<li>time saver</li>
</ul>
<h2 id="myths" class="content slide">myths</h2>
<h3 id="myths-1" class="content slide">it takes too much time</h3>
<ul class="list">
<li>saves time for debugging and bug fixing</li>
<li>saves time for development deployments</li>
<li>it makes your work more structured and less chaotic</li>
<li>it makes returning to project after a long break way easier and less stressful</li>
</ul>
<h3 id="myths-2" class="content slide">writing tests is difficult and complex</h3>
<ul class="list">
<li>it may be when you write tests after implementation because resulting code is not testable/structured wrong</li>
<li>it's easy when you write tests first and take small steps</li>
<li>changing mindset may be painful, but it's well worth it</li>
</ul>
<h3 id="myths-3" class="content slide">everything can be tested</h3>
<ul class="list">
<li>false, just use your judgement and test business logic that matters (eventually you will be testing small stuff too, it's that addicting :))</li>
</ul>
<h3 id="myths-4" class="content slide">tdd replaces architecture of the app</h3>
<ul class="list">
<li>architecture/design needs to be there</li>
<li>architecture gives the team boundaries they need, so that they may focus on driving the implementation with unit tests</li>
<li>what tdd gives you is early feedback about your architectural and design decisions</li>
</ul>
<h3 id="myths-5" class="content slide">tdd replaces qa</h3>
<ul class="list">
<li>NO, it doesn't</li>
<li>it's just a tool at developer disposal that, when applied correctly, gives a lot of advantages described above</li>
</ul>
<h2 id="how" class="content slide">how?</h2>
<ul class="list">
<li> thinking about tests first can be painful at the beginning, but becomes second nature quite soon</li>
<li> every mainstream language i know has some xUnit type of library, your favourite language have it as well</li>
<li> keep tests simple, new test = next smallest step on your way to full feature</li>
<li> keep tests dumb, just test states, no logic inside tests</li>
<li> use mocks for dependencies (develop with use of interfaces, so that implementation can be swapped!)</li>
<li> it's a good idea to create a few project-wide abstract classes for unit tests, as they will be reused a lot, create little DSL</li>
<li> too much 'verify' calls is a code smell</li>
<li> too much asserts in single method is a code smell (debatable tho)</li>
</ul>
<h2 id="tips" class="content slide">tips</h2>
<ul class="list">
<li> if there is a bug, write test first to reproduce it, then fix - this will make any regression bug to not appear again</li>
<li> time is a dependency, create time service and use mocking techniques to test time related code</li>
<li> after taking a break it's easy to lose context of what you are trying to do with your code, just leave one single test breaking and it will be easier to pick up your job later on and get into 'THE ZONE' faster</li>
<li> gamification - treat your tests as a progress metric, do small celebrations on each milestone (like 50 tests per day or project having 100/500/1000 tests), brag on company's chat about it</li>
<li> share with other developers how your test suite just saved you a lot of debugging or introducing some critical bug at production, this builds team confidence (i personally had a few stories where tests really helped keep everything in good condition despite me thinking i know better and nothing should fail after my changes)</li>
</ul>
<h2 id="coding" class="content slide">let's code</h2>
<ul id="toolbar">
<li class="slide-toggle"><a href="#toggle" rel="slide.toggle" title="Toggle slide show">Toggle slide show</a></li>
<li class="slide-prev slideshow-only"><a href="#prev" rel="slide.prev" title="Previous slide">Previous slide</a></li>
<li class="slide-next slideshow-only"><a href="#next" rel="slide.next" title="Next slide">Next slide</a></li>
</ul>
</body>
</html>