Unit Testing Unit Testing

Federico Lozada Mostohttp://www.mostofreddy.com.ar

@mostofreddy

@mostofreddy

@federicolozadamosto

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.

Características

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

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

Ventajas

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

Excusas

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

Estructura de un test

Arrange: Es la parte del test donde se configura e inicializa el test unitario

ActEs la parte donde se ejecuta el código de

la prueba unitaria

AssertEs la parte donde se prueba el resultado

del test unitario

Técnicas para hacer nuestro código más testeable

There is no secret to writing tests…… there are only secrets to writing testable code!

by Misko Hevery

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

Buenas prácticas

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

Mocks & test doubles

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

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.

StubReemplaza/simula una dependencia a una clase/módulo. El test tiene

el control sobre el Stub y puede predefinir valores de respuesta.

FakeClase programada para generar objetos que aparentan

un funcionamiento correcto.

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.

SpyStub pero además de cumplir su función, almacena información

como los métodos llamados.

Herramientas

PHP ............................. phpunit

Java ............................... JUnit

Net ................................ NUnit

Smalltalk ................. Sunit

Python ..................... PyUnit

Ruby ....................... Test::Unit

¿Preguntas?

@mostofreddy

@mostofreddy

@federicolozadamosto

Federico Lozada Mostohttp://www.mostofreddy.com.ar