Pruebas unitarias en profundidad

Transcripción

1 Pruebas unitarias en profundidad Luis Alfonso Rey 9º Encuentro Danysoft en Microsoft

2 Agenda Lo que ya sabemos Algunas cosas nuevas Despacito y buena letra Herencia de familia

3

4 Lo que ya sabemos Qué es una prueba unitaria y cuales deben ser sus características principales Qué son una pruebas de integración Qué es regresión Cómo hacer pruebas con Visual Studio Pero por si acaso

5 Prueba Unitaria Código que invoca código y establece condiciones de corrección Deben ser... Automatizables y repetibles Fáciles de implementar Reutilizables en el futuro Ejecutables por cualquiera Ejecutables pulsando un botón Lo más rápidas posible Solo un aspecto concreto

6 Prueba de regresión Una vez descubierto un error Se corrige pero puede volver a ocurrir Error de regresión Creemos pruebas para que no vuelva a suceder

7 Automatización de pruebas Como las pruebas unitarias son: Repetibles Reutilizables Ejecutables pulsando un botón Podemos dejar al sistema que las ejecute y luego nos informe del resultado

8 Pruebas de integración Pruebas que se efectúan en dos o más módulos dependientes entre si Es una prueba que puede tener efectos inesperados en otras partes Requiere análisis

9 Automatización vs. Integración La integración es buena pero Ha de ser repensada a cada modificación Normalmente el ejecutor ha de estar informado No suelen ser rápidas ni fáciles de ejecutar No suele ser automatizable

10 Pruebas unitarias en VS Framework de pruebas que incluye Proyectos Arneses y pruebas Métricas Ejecución automatizada Integración con sistemas de información

11

12 Novedades de Visual Studio 11 Beta Explorador de pruebas unitarias Soporte para frameworks Pero externos Mejoras de rendimiento Soporte 64Bit Pruebas asíncronas Framework de para fakes Mejoras en la cobertura de código Integración continua sin servidor Perdemos la intragración con el IDE

13

14

15 Algunas cosas nuevas Mas atributos en VS test framework Test Driven Development Stubs Mocks

16 Atributos de pruebas Clásicos TestClass, TestMethod, DataSource Inicialización AssemblyInitialize, ClassInitialize, TestInitialize Finalización AssemblyCleanup, ClassCleanup, TestCleanup Clasificación Owner, DeploymentItem, Description, HostType, Ignore, Priority, TestProperty, WorkItem TFS CssIteration, CssProjectStructure

17 Test Driven Development Primero Prueba luego codifica Pasos 1. Crea una prueba que falla 2. Crea el código para satisfacerla 3. Refactoriza si es necesario

18 Stubs Remplazo de una dependencia externa, evitando tratar directamente con ella class CardReader { public bool IsCardNumberValid (string number) { return SecuritySystem.IsCardNumberValid( number); [TestClass()] class CardReaderTest { [TestMethod()] public bool IsCardNumberValidTest () { string number = " "; CardReader reader = new CardReader(); Assert.IsTrue(reader.IsCardNumberValid( number));

19 Stubs Remplazamos en pruebas por stub Directivas Factory Constructor PropertyClass Injection de compilación [TestClass] class CardReader class { CardReaderTest { ISecuritySystem SecuritySystem; [TestMethod] public CardReader ( ISecuritySystem system) public { void IsCardNumberValidTest () { SecuritySystem = system string number = " "; CardReader reader = new CardReader(); reader.securitysystem #if DEBUG = SecuritySystemFactory.Create(); New FakeSecuritySystem(); Assert.IsTrue(reader.IsCardNumberValid( reader.securitysystem = FakeSecuritySystemFactory.Create(); number)); #endif Assert.IsTrue(reader.IsCardNumberValid( number)); Assert.IsTrue(reader.IsCardNumberValid( number));

20 Stubs Diferentes niveles de abstracción Constructor Injection Pocas referencias Obligatorias Property Injection Optativas Factory Class Clases sin constructores públicos Directivas de Compilación Factory class falsa

21 Mocks State-based Testing, probar el resultado por el estado final de un objeto Interaction Testing, probar como los objetos intercambian información Mock object un objeto falso que decide el resultado de la prueba en función de las interacciones del sistema con él Solo uno por test si probamos un aspecto

22 Mock vs. Stub Con Stub la clase falla en la prueba El Mock falla la prueba Objeto Prueba Stub class CardReader { public ISecurityDoor Door; public CardReader(ISecurityDoor door) { Door = door; public Objeto void OpenDoor() Mock { Door.Open(); [TestClass] class CardReaderTest { Prueba [TestMethod] public void OpenDoorTest () { ISecurityDoor door = new FakeSecurityDoor() CardReader reader = new CardReader(door); CardReader.OpenDoor(); Assert.IsTrue(door.IsOpen);

23 Mocks y Stubs manuales Costosos de implementar Difícil si las clases tienen interfaz complejo Mantener el estado es pesado y laborioso Difíciles de reutilizar Por eso existen varios frameworks

24 Algunos frameworks Nmock Moq Typemock Isolator Rhino Mocks Etc

25

26 Despacito y buena letra Las pruebas son buenas pero sin organización pueden resultar inútiles Ejecución frecuente Mantenimiento Clasificación por impacto y tiempo de ejecución Refactorización de pruebas y si es necesario API

27 Herencia de familia Las pruebas fáciles de integrar en proyectos nuevos y el código heredado qué? Difícil pero posible Para empezar señalar las partes necesarias Clasificarlas, más fáciles cuanto mas orientado a función, mas difíciles a la dependencia Grupos sin experiencia utilizar Easy-First Grupos con experiencia utilizar Hard-first Si refactorización primero crear pruebas de integración

28

29 Gestión activos software y libros

30 Formación, consultoría y seminarios

31