-
Notifications
You must be signed in to change notification settings - Fork 129
/
hacia-tests-unitarios.html
216 lines (177 loc) · 8.97 KB
/
hacia-tests-unitarios.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
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
<!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: Olores de código</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>Código y sus olores</h1>
<h3><a href="https://jj.github.io/curso-tdd/temas/hacia-tests-unitarios"><code>jj.github.io/curso-tdd/temas/hacia-tests-unitarios</code></a></h3>
</section>
<section><h1><em>Refinement</em></h1>
<h1>Gestión de dependencias separada de tareas evita
conflictos</h1>
<aside class="notes">Como me pasa a mi en polypoly,
cuando he añadido una tarea a un apartado en un
package.json, y me lo he cargado al actualizarlo dle
main.</aside>
</section>
<section><h1>✓ TODO</h1>
<h2 class="fragment">□ ¿Hemos comenzado a
organizar el desarrollo en milestones? </h2>
<h2 class="fragment">□ ¿Se han diseñado las
excepciones?</h2>
<h2 class="fragment">□ ¿Se han elegido un
<em>task runner</em> y se ha empezado a configurar?</h2>
</section>
<section><h1>El mejor código es el que no se
escribe</h1>
<h2 class="fragment">Código declarativo
FTW</h2>
<aside class="notes">Y el más seguro también</aside>
</section>
<section><pre><code data-line-numbers="1,3,8,13,16|7">from enum import Enum
IssueState = Enum('IssueState', 'Open Closed')
class Issue:
def __init__(self, projectName: str, issueId: int ):
self._state = IssueState.Open
self._projectName = projectName
self._issueId = issueId
def close(self):
self._state = IssueState.Closed
def reopen(self):
self._state = IssueState.Open</code></pre>
<aside class="notes">Usamos declaración de
variables y anotaciones de código para evitar
comprobaciones. Desgraciadamente, en Python no existen las
variables privadas, aunque convencionalmente estamos
declarando todos los atributos como
privados (con el _ delante)</aside>
</section>
<section><h1><em>Refinement</em></h1>
<pre><code data-line-numbers="1,6|9-11">from enum import Enum
from dataclasses import dataclass
IssueState = Enum('IssueState', 'Open Closed')
@dataclass
class Issue:
projectName: str
issueId: str
state: IssueState = IssueState.Open
def close(self):
self.state = IssueState.Closed
def reopen(self):
self.state = IssueState.Open</code></pre>
</section>
<section><!-- Buenas prácticas -->
<section><h1>DRY: No te repitas</h1>
<h2 class="fragment">Limpia tu código</h2>
</section>
<section><h1>Reflexionar sobre las
repeticiones</h1>
<pre><code>method new-issue( Project::Issue $issue where $issue.project-name eq
$!project-name) {…}
multi method new-milestone( $milestone where $milestone.project-name eq
$!project-name) {…}
</code></pre>
<aside class="notes">En este caso, se
puede estar indicando que tanto los issues
como los milestones no deberían estar
<em>fuera</em> del proyecto sino dentro,
porque al final no tiene mucho sentido
definir un milestone fuera del contexto de
un proyecto (ni un issue)</aside>
</section>
<section><h1>Evitar los números mágicos</h1>
<h2 class="fragment">Código limpio y sin
encantamientos</h2>
</section>
<section data-transition="fade"><h1>Identificar los valores</h1>
<pre><code data-line-numbers="7,9">import ../project
var
thisProject: Project
thisProject = Project( id: "Foo" )
assert thisProject.id == "Foo"</code></pre>
<aside class="notes">Nim usa "const" para
sus constantes, y en este caso la usamos
para identificar tanto el valor como el
resultado de un test</aside>
</section>
<section data-transition="fade"><h1>Valores identificados</h1>
<pre><code data-line-numbers="3,7,9">import ../project
const projectId= "Foo"
var
thisProject: Project
thisProject = Project( id: projectId )
assert thisProject.id == projectId</code></pre>
<aside class="notes">Nim usa "const" para
sus constantes, y en este caso la usamos
para identificar tanto el valor como el
resultado de un test</aside>
</section>
<section data-background="https://live.staticflickr.com/382/18606570955_cb78e7c8c0_3k_d.jpg"><h1>Algo huele mal en tu código</h1>
<h2 class="fragment"><em>Code smells</em>,
código idiomático, antipatrones y
otros pecados</h2>
</section>
<section><h1>Usa <em>linters</em></h1>
<h2 class="fragment">Examinan
estáticamente el código, dan consejos para
respetar convenciones</h2>
</section>
<section><h1>Mi código apesta</h1>
<pre><code data-line-numbers="1|2-4|6">Project/core.py:10:0: W0301: Unnecessary semicolon (unnecessary-semicolon)
Project/core.py:1:0: C0114: Missing module docstring (missing-module-docstring)
Project/core.py:1:0: C0115: Missing class docstring (missing-class-docstring)
Project/core.py:6:4: C0116: Missing function or method docstring (missing-function-docstring)
…
Project/core.py:9:4: C0103: Method name "newMilestone" doesn't conform to snake_case naming style (invalid-name)
-----------------------------------
Your code has been rated at 0.00/10
</code></pre>
<aside class="notes">En ciertos lenguajes
son más estrictos que en otros sobre cómo se
debe escribir, pero escribir siguiendo las
buenas prácticas también es una práctica
defensiva que ayuda a que otras personas
inviertan menos tiempo en entenderlo, o en
refactorizarlo si es que se fusiona con otra
base de código que sí las siga</aside>
</section>
</section>
<section><h1>✓ TODO hito 10</h1>
<h2 class="fragment">Elegir un linter y empezar
a usarlo</h2>
<h2 class="fragment"><code>agil.yaml</code> ⇒</h2>
<pre class="fragment"><code>linter: RuboCop
</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>