Presentanción con conceptos de que es el testing unitario.
- Características
- Ventajas
- Excusas
- Estructura de un test
- Técnicas para hacer nuestro código mas testeable
- Buenas prácticas
- Mocks & test doubles
- Herramientas
3. Una prueba unitaria es una forma de probar el correcto
funcionamiento de una unidad funcional de forma aislada.
Esto sirve para asegurar que cada unidad funcione correctamente.
5. Automatizable
Deben poder ejecutarse de forma automática
sin intervención manual
Predecible
Deben devolver el mismo resultado sin importar
la cantidad de veces que se corran
Enfocada
Cada test se debe estar enfocado a una unidad funcional
6. Ejecución rápida
Deben ejecutarse rápidamente
Aisladas/independiente
No deben afectar a otro test, unidada funcional
ni acceder a recursos del sistema
Desarrollo rápido
Simples y fáciles de desarrollar
Profesional
Debe ser código como si fuera producción
8. Mejora la calidad del código y su arquitectura
Facilita la refactorización
Documenta el código
Detecta bugs tempranamente
Ayuda a tener un código mas desacoplado
Simplifica la integración entre sistemas
10. El código es fácil de testear
El test no forma parte del desarrollo
Los desarrolladores no quieren escribir los test
Cuesta mucho tiempo hacer los test
Testing es para QA
12. Arrange:
Es la parte del test donde se configura e
inicializa el test unitario
Act
Es la parte donde se ejecuta el código de
la prueba unitaria
Assert
Es la parte donde se prueba el resultado
del test unitario
13. There is no secret to writing tests…
… there are only secrets to writing testable code!
by Misko Hevery
Técnicas para hacer nuestro
código más testeable
14. Programar orientado a interfaces
Usar la ley de Demeter y los principios SOLID
Definir la correcta responsabilidad en cada clase y método
Evitar métodos largos
Aislar dependencias y utilizar Inversión de Control
No realizar tareas en el método constructor
Preferir la dependencia ante la herencia
Evitar el patrón Singleton
16. Cada test debe ser independiente al resto
Un test debe probar solo una unidad lógica
Debe haber un solo assert por test
Nombre descriptivo
Implementar test dobles para las dependencias
18. Sometimes it is just plain hard to test the system under test (SUT)
because it depends on other components that
cannot be used in the test environment.
This could be because they aren't available,
they will not return the results needed for the test
or because executing them would have
undesirable side effects.
In other cases, our test strategy requires us to have more control
or visibility of the internal behavior of the SUT.
When we are writing a test in which we cannot (or chose not to)
use a real depended-on component (DOC),
we can replace it with a Test Double.
The Test Double doesn't have to behave exactly like the real DOC;
it merely has to provide the same API
as the real one so that the SUT thinks it is the real one!
– Gerard Meszaros
19. Mock:
Un mock de una interfaz nos sirve para confirmar que los métodos
de la interfaz se han llamado correctamente durante la ejecución del test.
Stub
Reemplaza/simula una dependencia a una clase/módulo. El test tiene
el control sobre el Stub y puede predefinir valores de respuesta.
Fake
Clase programada para generar objetos que aparentan
un funcionamiento correcto.
20. Dummy:
Objetos usados para rellenar o ser pasados por parámetro.
De implementación pueden estar vacíos, ya que no van a ser usados
directamente.
Spy
Stub pero además de cumplir su función, almacena información
como los métodos llamados.