Es bueno ver que todo funciona y que se cumplen todas las expectativas de la prueba, pero a nuestro conjunto de pruebas le faltan algunas partes muy importantes. Hasta ahora, sólo hemos escrito pruebas que simulan un usuario «agradable» que introduce valores normales y no intenta hacer nada fuera de lo normal.
Podríamos tener más usuarios adversarios que representen casos límite, o cosas que nuestro código no tiene en cuenta. En este ejemplo, los casos de borde incluyen:
- tratando de calcular con entradas vacías
- entrando en las entradas de la basura como bla bla bla o Robert$0027); estudiantes de DROP TABLE;–
- introduciendo 0 tanto para el peso como para la altura, lo que hace que la fórmula del IMC sea indefinida (debido a la forma indeterminada 0/0)
La calculadora no tiene ningún código para hacer la validación de la entrada, así que estos eventos podrían desencadenar algún comportamiento inesperado.
En este punto se puede esperar que escribamos un código de validación de entrada, y luego escribamos pruebas para verificar que la validación funciona correctamente. En realidad, haremos esos pasos en el orden contrario. Primero escribiremos pruebas para la validación de entrada, y luego escribiremos el código para implementar realmente la validación de entrada.
¿Por qué es importante el orden? Si escribimos las pruebas primero, entonces las pruebas pueden ayudarnos a encontrar problemas en el código a medida que lo escribimos, y nos ayudan a llevar un registro de las cosas que hemos terminado y lo que aún nos queda por hacer. Si, por otro lado, escribiéramos el código primero, entonces nos arriesgaríamos a escribir las pruebas para que se ajusten al código que ya hemos escrito. Esto frustraría el propósito de escribir pruebas (aunque estas pruebas aún ayudarían a encontrar las regresiones).
Para decirlo de otra manera, escribir pruebas que coincidan con el código que ya hemos escrito puede ser como disparar una flecha, luego dibujar un blanco alrededor de la flecha y presumir de que has dado en el blanco. Al igual que este blanco sería inútil para evaluar su habilidad con el arco, las pruebas que se ajustan demasiado a su código no proporcionan ninguna información útil.
Notarán que no escribí los exámenes primero en el comienzo de este tutorial, y es justo preguntarse por qué no. A menudo hago una excepción con el prototipo inicial, ya que todavía está explorando la estructura básica de la aplicación y podría hacer muchos cambios en sus ideas iniciales de cómo deberían comportarse las cosas. Una vez que ya tienes la estructura básica de tu aplicación algo asentada, es más fácil construir iterativamente encima de ella de una manera probada.
Escribamos nuestras pruebas para la validación de la entrada. La idea básica es que
- Si se introducen entradas no válidas, se mostrarán mensajes de error sin ningún resultado de basura.
- La introducción de entradas válidas muestra los resultados de los cálculos sin ningún mensaje de error.
Añadiremos otra etapa al archivo de pruebas BMICalculator.js. Primero, probablemente añadiremos algún contenedor para mostrar mensajes de error, así que añadiremos un selector para ello:
12345var selectores ={//... resultado: "#resultado", error: "#error"};
javascript
Luego crearemos una lista de entradas de prueba y determinaremos si cada entrada debe disparar un mensaje de error:
1234567891011121314151617var esperadoValidación de entrada =["","",false],["100", "100",true],["100","",false],["", "100", falso],["40", "100",verdadero],["100", "40",verdadero],["NaN", "100",falso],["100", "NaN",falso],["bla bla bla", "123",falso],["1". 35", "4.43",verdadero],["35","{]{]}%^@#^",falso],["rm -rf /", "Robert$0027); DROP TABLE estudiantes;--",falso],["100", "0",verdadero],["0", "100",verdadero],["0", "0",falso]];
javascript
Por último, añadimos una etapa de prueba que se ejecutará a través de nuestra serie de pruebas y comprobar cada una de ellas:
1234567891011121314151617181920212223242526272829303132module.exports={"Open page":function(browser){/* … */},"Emite valores esperados":function(browser){/* … */},"Valida la entrada":function(browser){for(var i =0; i &lt; expectedInputValidation.length; i++){var values = expectedInputValidation[i], weight = values[0], height = values[1], isValid = values[2]; browser .clearValue(selectors.weight).setValue(selectors.weight, weight).clearValue(selectors.height).setValue(selectors. height, height).click(selectores.submit);if(isValid){ el.navegador.espera.que.el.elemento(resultado.de.los.selectores).sea.visible;.el.navegador.espera.que.el.elemento(error.de.los.selectores).no.sea.visible;}else{ el.navegador.espera.que.el.elemento(resultado.de.los.selectores).no.sea.visible;.el.navegador.espera.que.el.elemento(error.de.los.selectores).sea.visible;},"Cerrar.página.":function(navegador){/* … */}};</pre ]..;
javascript
Si quieres acelerar las cosas un poco, puedes poner un retorno; al principio de la "Salidas valores esperados" etapa para saltar esas pruebas.
Ejecutando la vigilancia nocturna -t pruebas/BMICalculadora ahora debería producir algo como esto:
FALLO DE PRUEBA: 1 aseveraciones fallaron (2.024s)———————————————————————————–FALLO DE PRUEBA: 1 aseveraciones fallaron, 1 pasaron (7.02s) ? BMICalculadora – Valida la entrada Elemento esperado &lt;#resultado&gt; no ser visible – Esperado "no visible" pero tiene: "visible" SALTADO: – Cierra la página</pre
Las pruebas fallaron. Eso… es algo bueno. Si las pruebas de validación pasaron antes de que escribiéramos el código de validación, eso significaría que algo está mal en las pruebas.
Para implementar la validación de la entrada, modifique el archivo BMICalculator.html de la siguiente manera:
…123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354&lt;style&gt;#resultado, #error{visión: ninguno;}/* … */&lt;/estilo&gt;&lt;!– … –&gt;&lt;form&gt;&lt;!– … –&gt;&lt;p&gt;Su índice de masa corporal es &lt;span&gt;&lt;/span&gt;. Tu eres &lt;span&gt;&lt;/span&gt;.&lt;/p&gt;&lt;p&gt;&lt;/p&gt;&lt;/form&gt;&lt;script&gt;//… functionvalidateInput(altura, peso){var errores =[];if(altura ==="") errors.push("El campo de la altura está vacío.");if(isNaN(altura)) errors.push("La altura introducida no es un número válido. &cuota;);si(peso ===&cuota;&cuota;) errores.push(&cuota;El campo del peso está vacío.&cuota;);si(esNaN(peso)) errores.push(&cuota;El peso introducido no es un número válido. ");if(altura ==="0"&amp;quot;amp;quot; peso ==="0") errores.push("La altura o el peso deben ser distintos de cero.");errores de retorno;}var form =documento.forms[0], result =documento. getElementById("result"), bmiSpan =documento.getElementById("bmi"), categorySpan =documento.getElementById("category"), error =documento. getElementById("error"); form.onsubmit=function(){var height = form.height.value, weight = form.weight.value;var errors =validateInput(height, weight);if(errors.length){ error.innerHTML= errors. join("&lt;br&gt;"); error.style.display="block";; result.style.display="none";returnnfalse;}var bmi =calcular IMC(peso, altura), category =getCategory(bmi); result. style.display="block";; error.style.display="none";; bmiSpan.innerText= bmi.toFixed(2); categorySpan.innerText= category;returnfalse;};&lt;/script&gt;</pre>
html
Ahora, si hacemos la Vigilancia Nocturna, las pruebas deberían pasar:
…de acuerdo. 172 afirmaciones totales aprobadas. (30.673s)||||||||||||||||||de acuerdo con la ley;
(Si te saltaste la etapa de "Salidas de valores esperados", entonces el número será 31 en lugar de 172.)