No es si estás haciendo pruebas unitarias. Es si lo estás haciendo bien, ¿estás obteniendo todo el valor de ello?
Pruebas unitarias como una forma de vida : si está haciendo pruebas unitarias como una forma de vida, tendrá una buena intuición sobre cuándo usarlas. Tiene grandes ventajas
1. Fragmentos de código: escribir pequeños fragmentos de código que manejan pequeños fragmentos de código se convierte casi en una necesidad. Esto también conduce al desarrollo iterativo (¡gran victoria!). Cuando estás haciendo pruebas unitarias, no atacas un problema / característica en su conjunto. Tú haces partes de eso. Imagine una función en la que tiene que hacer algunas llamadas al servicio web, analizar los resultados y devolver algunos objetos con los resultados. Recortaría el servicio web de llamada, probaría y, en efecto, lo parametrizaría correctamente. Luego haga lo mismo para el análisis de resultados y la creación de objetos. Voila, básicamente has creado una característica completa haciendo solo experimentación. Esto es lo que las personas hacen en el REPL cuando codifican. Son pruebas unitarias. O podría decir que las pruebas unitarias son su REPL.
- ¿Cuál es el mejor entorno de desarrollo para Rails en una Mac?
- ¿Cuáles son las principales diferencias entre un ingeniero de interfaz de usuario, un desarrollador web y un ingeniero?
- ¿Cómo se compara el desarrollo con Django en Windows con el desarrollo con Django en Linux? ¿Cuáles son las compensaciones?
- Cómo mejorar la tasa de clics de mi sitio web
- ¿Qué quieres decir con complementos en JavaScript y complementos en Java? ¿Por qué usamos complementos?
2. Depuración más fácil: cualquier error ocurre durante el ciclo de vida de un hilo de ejecución. En cualquier base de código esto podría ser bastante complicado. Con Unit Testing, básicamente puede dividir esto en piezas y hacer una búsqueda binaria de la pieza que está fallando. Enlace sutil a git bisect. Reproducir un error es fácil, simplemente escriba una prueba y, una vez que lo haga, ¡el código futuro no puede dañarlo!
3. La Ley de Permutación – Digamos que una clase tiene 5 casos de prueba. La siguiente clase tiene 5 casos de prueba y así sucesivamente hasta 5 clases de profundidad hasta llegar a sus modelos de dominio. Pruebas unitarias – 5 * 5 = 25 pruebas. Total de flujos de código posibles: 5 ^ 5 – 3125. ¡Gran victoria!
4. La Ley de Entrada / Salida: una gran cantidad de programación informática (salvo esos efectos secundarios desagradables) puede reducirse a b = f (a). Usted da una entrada y obtiene una salida. Simple. Agregue suficiente de estos juntos y tendrá algo. Hay una razón por la que esos tipos de programación funcional siguen hablando de efectos secundarios.
5. Esa ley de cambios: en realidad, la mayoría de las pruebas solo son útiles si cambia el código después de escribirlo una vez. En realidad, la mayor parte del código requiere eso. Aso, el punto emerge. En realidad, es principalmente útil.
6. Organiza la estructura del código y los pensamientos. Viste que eso sucedía, ¿no?
Ahora no siempre es completamente bueno. Habrá fanáticos que te lo dirán. No los escuches, y mejor mantente / huye de ellos.
Cobertura de velocidad / prueba : sea pragmático. No necesita probar cada centímetro del código. Prueba lo que te aporta más valor. Asegúrate de tener suficientes pruebas para arrancar la mayoría de las partes de la aplicación de forma independiente y jugar con ellas. Realmente no apunte a una cobertura de prueba completa.
Ya sabes cómo los niños aprenden a programar, hacen un cambio y ven su efecto. Si se rompe o funciona. Así es como aprenden y así es como deberíamos programar como adultos también. Olvidamos eso a mitad de camino, y hacemos estas bestias complicadas de las que no sabemos lo que está sucediendo dentro. Su código siempre debe ser algo que pueda modificar y ver si se rompe o funciona, o cómo reacciona. Pierde esto y, básicamente, ya no puedes jugar con tu código. Tu cerebro está jodido.
Inversión – ¿Qué pasa si no sé todo esto? ¿Vale la pena la inversión? En mi experiencia, la inversión en pruebas unitarias y configuración de CI generalmente paga su costo inicial mejor que el oro puro.
Hacerlo bien – Cuadro negro, siempre cuadro negro (repita después de mí y escríbalo en la pizarra 5 veces) – La programación está diseñada alrededor de interfaces, la verdadera abstracción. Tal debería ser su prueba. Debe probar una función sin saber lo que contiene. Si lo haces, lo estás haciendo mal. No adivines el flujo del código. No intentes burlarte de cada pequeño aspecto del código que estás probando. Está mal, no importa cuán importante sea el programador diciéndote eso. Siempre debe probar lo que hace la función, no cómo lo hace.
Ahora la parte final y más importante que realmente fue el punto central de todo esto. No lo use cuando realmente no lo necesite. Si siente que se ve obligado a escribir pruebas en una línea de montaje, lo está haciendo mal. Tal vez incluso eso esté bien cuando el producto ha alcanzado un cierto nivel de madurez. Las cosas nuevas no deben probarse de manera rígida a menos que sea google / ms / facebook, etc.
Además, escriba buenos casos de prueba. Eso requiere imaginación. No es estrictamente una habilidad de programación en realidad. Es una habilidad ligeramente diferente, que tienen los probadores tenaces y los hackers de seguridad.
No muchos programadores son tan buenos y a menudo compensan exagerando las pruebas (escribiendo 25 simulacros y verificando si se llamó a cada línea del código y capturando los argumentos llamados dentro de la función) y despreciando a otros que no siguen su ensamblaje línea. Básicamente son idiotas que malgastan el dinero del cliente y de las empresas. Pero entonces la informática también tiene su religión 🙂
Salir adelante. Que las xUnits te acompañen
