-
Notifications
You must be signed in to change notification settings - Fork 129
/
tests-unitarios-organización.html
152 lines (130 loc) · 6.59 KB
/
tests-unitarios-organización.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
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<title>Desarrollo ágil: Organización de los tests unitarios</title>
<link rel="stylesheet" href="dist/reset.css">
<link rel="stylesheet" href="dist/reveal.css">
<link rel="stylesheet" href="dist/extra.css">
<link rel="stylesheet" href="dist/agil.css" id="theme">
<!-- Theme used for syntax highlighted code -->
<link rel="stylesheet" href="plugin/highlight/monokai.css" id="highlight-theme">
</head>
<body>
<div class="reveal">
<div class="slides">
<section><h2>Desarrollo ágil</h2>
<h1>Organizando los tests unitarios</h1>
<h3><a href="https://jj.github.io/curso-tdd/temas/tests-unitarios-organización"><code>jj.github.io/curso-tdd/temas/tests-unitarios-organización</code></a></h3>
</section>
<section><h2>✓ TODO</h2>
<h2 class="fragment">□ ¿Se han diseñado las
excepciones y definido claramente clases?</h2>
<h2 class="fragment">□ ¿Se ha elegido y
comenzado a usar un linter?</h2>
</section>
<section><h1>Se comprueban
<strong>comportamientos</strong></h1>
<h2 class="fragment">Reflejados en las
historias de usuario</h2>
<aside class="notes">Es muy importante que sólo se
comprueben comportamientos, y no interpretaciones
específicas del comportamiento o el estado actual de la
implementación. Sin las HU, los tests no tienenn ningún sentido.</aside>
</section>
<section><h1>Los tests <strong>unitarios</strong>
se refieren a las capas (de abstracción) más
bajas</h1></section>
<section><h1>Y se implementan en bibliotecas de
aserciones</h1>
<aside class="notes">Que también hay que
elegir, antes de plantearse escribir el
principio de los tests. Casi siempre hay
una biblioteca de tests unitarios estándar,
pero suele haber otras posibilidades, o un
montón en JavaScript. Hay que tener cuidado de reflejar
bien esta elección, o nos podemos encontrar con varias
bibliotecas, una en cada submódulo</aside>
</section>
<section><!-- plan, setup, test, teardown -->
<section data-background="https://live.staticflickr.com/14/20059863_dc04b9bfb5_o_d.jpg"><h1>Planifica</h1>
<h2 class="fragment">Número de tests</h2>
<h2 class="fragment">Subtests</h2>
<h2 class="fragment">Precondiciones</h2>
</section>
<section><h1>Ejecutar en caso de...</h1>
<pre><code data-line-numbers="1,5|3-5">use Test::More;
unless ( $ENV{'TRAVIS_PULL_REQUEST'} =~ /\d/ ) {
plan skip_all => "Check relevant only for PRs";
} </code></pre>
<aside class="notes">Ya no usamos Travis, pero es un ejemplo.</aside>
</section>
<section><h1><em>Setup</em>: crear objetos que
se testearán</h1>
<h2 class="fragment">Que <em>no son parte
del test</em></h2>
</section>
<section><h2><em>Fixtures</em> en
Python</h2>
<pre><code data-line-numbers="1|7-11|13">import pytest
from Project.Issue import Issue, IssueState
PROJECTNAME = "testProject"
ISSUEID = 1
@pytest.fixture
def issue():
issue = Issue(PROJECTNAME,ISSUEID)
return issue
def test_is_open_when_created(issue):
assert issue.state == IssueState.Open </code></pre>
<aside class="notes">Esto corresponde a
una historia de usuario que dice que cuando se cree un issue debe
estar abierto</aside>
</section>
<section><h1>O leer datos</h1>
<pre><code data-line-numbers="1|3">func TestMain(m *testing.M) {
ReadsFromFile("./hitos_test.json") // Alternative test file
os.Exit(m.Run())
}</code></pre>
<aside class="notes">Esta función
ejecuta directamente el test con m.Run,
saliendo con el estado que haya
producido. También se ve aquí cómo Go usa
los códigos de estado para indicar
excepciones o no</aside>
</section>
<section><h1>Dejarlo todo limpito:
<em>teardown</em></h1>
<h2 class="fragment">Más común en tests de
integración</h2>
</section>
</section>
<section><h1>✓ TODO hito 11</h1>
<h2 class="fragment">Elegir una biblioteca de
aserciones y preparar para los tests</h2>
<h3 class="fragment"> En
<code>agil.yaml</code></h3>
<pre class="fragment"><code data-line-numbers="1,2|3">test:
- tests/fichero-test.jl
aserciones: "@test" </code></pre>
</section>
</div>
</div>
<script src="dist/reveal.js"></script>
<script src="plugin/notes/notes.js"></script>
<script src="plugin/markdown/markdown.js"></script>
<script src="plugin/highlight/highlight.js"></script>
<script>
// More info about initialization & config:
// - https://revealjs.com/initialization/
// - https://revealjs.com/config/
Reveal.initialize({
hash: true,
width: "95%",
slideNumber: true,
// Learn about plugins: https://revealjs.com/plugins/
plugins: [ RevealMarkdown, RevealHighlight, RevealNotes ]
});
</script>
</body>
</html>