You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: temas/cobertura.md
+3-4
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,5 @@
1
1
# Tests de cobertura
2
2
3
-
4
3
## Planteamiento
5
4
6
5
Si el código no se ha probado, no funciona. Los tests de cobertura nos
@@ -24,7 +23,7 @@ por los tests unitarios (que, recordemos, son de caja blanca y por
24
23
tanto se puede saber qué camino han seguido por el mismo). Estos tests
25
24
de cobertura funcionan tanto a nivel de línea, como de función o de
26
25
paquetes, pero generalmente van a dar un porcentaje de líneas
27
-
cubiertas por los tests unitarios.
26
+
cubiertas por los tests unitarios.
28
27
29
28
Dependiendo del lenguaje, se hará con unas herramientas u otras. En general, constarán de dos partes:
30
29
@@ -52,7 +51,7 @@ nombre indicado, y la segunda orden abre un navegador con una página
52
51
en la que nos muestra nuestro código y la cobertura que tiene,
53
52
señalando las funciones y líneas que no están cubiertas. Sobre la clase [`HitosIV` que ya hemos usado anteriormente](https://github.com/JJ/HitosIV), estos serían los resultados.
54
53
55
-

54
+

56
55
57
56
En este caso, las líneas no cubiertas eran las que lanzaban errores en caso de que
58
57
se encuentren algún problema. No siempre es obligatorio que cubrir el 100% de las
@@ -64,7 +63,7 @@ debemos
64
63
asegurar que sigue las mejores prácticas del lenguaje:
65
64
66
65
67
-

66
+

68
67
69
68
Siempre es mejor en Go devolver un error que enviar a registro un error fatal, así que este cambio en el código asegura que se pueda cubrir mejor con los tests.
0 commit comments