42

Author: andersontr15

README.md

@@ -1609,14 +1609,8 @@ inventoryTracker.requestItems();
 **[⬆ vuelve hasta arriba](#contenido)**
 
 ## **Pruebas**
-Comprobar nuestro codigo es más importante que enviarlo. Si no tienes 
-pruebas o tienes una cantidad inadecuadas, cada vez que envías tu codigo tendras dudas en cuanto el saber de cuantos errores aún existen en tus programas. Deducir en lo que constituye una cantidad adecuada es la responsabilidad del equipo, pero tener cobertura 100% (todos las declaraciones y ramos) es como se logra una confianza alta y una tranquilidad de mente.
-Esto significa que encima de utilizar una estructura de pruebas, también necesitas usar 
-una [buena herramienta de coberatura](http://gotwarlost.github.io/istanbul/).
-
-No existe excusa para no escribir pruebas. Hay [muchas estructuras buenas de pruebas para JS](http://jstherightway.org/#testing-tools), asi que busca una que le guste tu equipo. 
-Cuando encuentras una que tu equipo le gusta, enfócate en siempre escribir pruebas 
-para cada nueva característica/módulo que introduces. Si tu método preferido es el Test Driven Development (TDD), eso está bien, pero el punto principal es que te aseguras de llegar a tus objetivos de cobertura antes de enviar el código o refactorizar una prueba ya existente.
+Comprobar nuestro codigo es más importante que enviarlo. Si no tienes pruebas o tienes una cantidad inadecuadas, cada vez que envías tu codigo tendras dudas en cuanto el saber de cuantos errores aún existen en tus programas. Deducir en lo que constituye una cantidad adecuada es la responsabilidad del equipo, pero tener cobertura 100% (todos las declaraciones y ramos) es como se logra una confianza alta y una tranquilidad de mente. Esto significa que encima de utilizar una estructura de pruebas, también necesitas usar una buena herramienta de cobertura.
+No existe excusa para no escribir pruebas. Hay muchas estructuras buenas de pruebas para JS, así que busca una que le guste tu equipo. Cuando encuentras una que tu equipo le gusta, enfócate en siempre escribir pruebas para cada nueva característica/módulo que introduces. Si tu método preferido es el Test Driven Development (TDD), eso está bien, pero el punto principal es que te aseguras de llegar a tus objetivos de cobertura antes de enviar el código o refactorizar una prueba ya existente.
 
 
 ### Un solo concepto cada prueba