Pruebas en Visual Studio XII Encuentro Danysoft en Microsoft Directos al código

Transcripción

1 Pruebas en Visual Studio XII Encuentro Danysoft en Microsoft Directos al código Jorge Bustos Servicios Profesionales Abril 2015 Día TFS Introducción a las pruebas Ejecución de pruebas en Visual Studio Las pruebas no resuelven todo 1

2 Introducción a las pruebas Clasificación: Estáticas/dinámicas Caja blanca / caja negra Nivel: unitarias / de integración / de sistema Manuales / automáticas Otras clasificaciones: regresión, aceptación, IU Coste de las pruebas Qué se gana con las pruebas Estáticas / dinámicas Pruebas estáticas: Sin ejecución de código Dinámicas: Con ejecución de código 2

3 Variación del algoritmo de Dijkstra (1959) Edsger W. Dijkstra 11/5/1930 6/8/2002 Caja blanca / negra Caja blanca: Se conoce y prueba la estructura del programa Caja negra: Se prueba sin tener en cuenta la estructura 3

4 Citando a Dijkstra A convincing demonstration of correctness being impossible as long as the mechanism is regarded as a black box, our only hope lies in not regarding the mechanism as a black box Citando a Dijkstra Una demostración convincente de la corrección es imposible si se trata el mecanismo como una caja negra; nuestra única esperanza está en no tratar el mecanismo como una caja negra 4

5 public class Calculadora { public int Suma (int a, int b) { } } return 2; Y si comprobamos que Suma(1,1) = 2? Pruebas de caja negra Problema, por el desconocimiento del código es posible: hacer muchas pruebas que prueban el mismo código dejar partes del código o casos sin probar Ventaja: probar cosas que al desarrollador no se le ocurren 5

6 Pruebas de caja blanca Al conocer la estructura del programa: Es más fácil determinar que pruebas deben hacerse para cubrir más casos y más código Si las hace el propio desarrollador puede que sólo pruebe lo que sabe que funciona (maldito subconsciente) Otras clasificaciones Pruebas de regresión: Comprobar que nada se ha roto tras modificar el software Pruebas de aceptación: Generalmente hechas por el cliente para dar el visto bueno Rendimiento, Usabilidad, Accesibilidad, Seguridad, Interfaz de usuario, Internacionalización 6

7 Clasificación por niveles Pruebas unitarias: Prueba una funcionalidad de un componente, aislada del resto del sistema Pruebas de integración Prueba varios componentes trabajando juntos Pruebas de sistema Prueba el software completo Pirámide de pruebas Menos pruebas Ejecución lenta Más inestables Amplio alcance IU Integración Unitarias Alcance limitado Más estables Ejecución rápida Más pruebas 7

8 Pruebas en el ciclo de desarrollo TDD Integración continua Prueba continua BDD Citando a Dijkstra When we take the position that it is not only the programmer's responsibility to produce a correct program but also to demonstrate its correctness in a convincing manner, then the above remarks have a profound influence on the programmer's activity: the object he has to produce must be usefully structured 8

9 Citando a Dijkstra si la responsabilidad del programador no es sólo producir un programa correcto, sino también demostrar su corrección de una manera convincente, [ ] esto tiene una profunda influencia en su actividad: el objeto que produce tiene que estar estructurado de manera útil Qué ganamos con las pruebas Para nuevas aplicaciones: calidad del código reducción de nº de bugs llegados a producción Aplicaciones heredadas: Red de seguridad para la refactorización 9

10 Coste de las pruebas Probar supone: definir y realizar pruebas Hay que buscar equilibrio entre el coste y el beneficio de las pruebas: Probar levemente las partes poco usadas/ poco críticas / más sencillas de implementar Probar exhaustivamente las partes más usadas, más críticas y más complicadas Pruebas manuales y automáticas Manuales: Requieren la intervención de una persona para su ejecución Automáticas: Se ejecutan sin intervención de una persona, produciendo un resumen de los resultado 10

11 Ejecución de pruebas en Visual Studio Todo el mundo prueba Pruebas automáticas Fases de las pruebas Definición y ejecución Prueba de integración, unitaria y sustitutos Estilos: verificación de estado y de comportamiento Cobertura de las pruebas No todos los errores son bugs Todo el mundo prueba sus programas Prueba: cualquier cosa que hacemos para comprobar que un programa funciona correctamente, e incluye: The chapuzero s way 11

12 Pruebas automáticas Las pruebas automáticas: Tienen menor coste Se ejecutan más veces Se pueden integrar en procesos (TDD, Integración continua, refactorización de aplicación heredada...) De muchos tipos, incluyendo unitarias, de integración, de IU Ejecución de pruebas en Visual Studio Visual Studio permite ejecutar pruebas automáticas No siempre son unitarias! 12

13 Fases de las pruebas AAA: Arrange Act Assert 4 fases: Setup Exercise Verify Tear-down Definición y ejecución de pruebas Elegir un framework para definir las pruebas: MSTest, NUnit, xunit, Jasmine, QUnit Ejecutar las pruebas: Test Runner de Visual Studio, adaptador, test runner externos, en procesos de CI... 13

14 Demo: definición de pruebas Definición de pruebas con dos frameworks: MSTest NUnit [TestFixture] public class CalculadoraTestNUnit { [Test] public void Suma1mas1_da2() { Calculadora calc = new Calculadora(); var suma = calc.suma(1, 1); Assert.AreEqual(2, suma); } [Test] [ExpectedException( typeof(dividebyzeroexception))] public void DivideEntreCero_LanzaExcepcion() { Calculadora calc = new Calculadora(); calc.divide(12, 0); } } [TestClass] public class CalculadoraTest { [TestMethod] public void Suma1mas1_Da2() { Calculadora calc = new Calculadora(); var suma = calc.suma(1, 1); Assert.AreEqual(2, suma); } [TestMethod] [ExpectedException( typeof(dividebyzeroexception))] public void DivideEntreCero_LanzaExcepcion() { Calculadora calc = new Calculadora(); calc.divide(12, 0); } } 14

15 Prueba unitaria frente a prueba de integración Unitaria: prueba una funcionalidad individual, quitando las dependencias de otros módulos Integración: prueba una funcionalidad completa, que involucra varios módulos Sustitución de dependencias En el mundo real las clases tienen dependencias Para garantizar que la prueba funciona, las dependencias deben sustituirse con doubles, dummies, stubs, spies, fakes, mocks... Para sustituirlas, las dependencias deben ser interfaces, no clases (si no queda otro remedio, métodos virtuales) 15

16 Ejemplo de dependencias Notificador Servidor GestorVentas PasarelaPago Servidor pagos Almacen Base de datos Sustitución de dependencias (2) Las dependencias deben estar accesibles: Si hay inyección de dependencias por constructor ya lo tenemos Si no, ofrecer constructor alternativo o propiedades para poder remplazar dependencias Para casos extremos (por ej. método estático como DateTime.Today), usar shims (o JustMock) 16

17 Demo: prueba integración Prueba de integración Estilos de pruebas unitarias Verificación de estado Establece estado inicial, actúa, comprueba estado final Verificación de comportamiento Ejecuta prueba y verifica que se han realizado las llamadas esperadas a las dependencias 17

18 Demo: sustitución clásica Prueba clásica, con sustitutos creados a mano Mocks Frameworks para crear dinámicamente sustitutos para pruebas: Permiten remplazar comportamientos Permiten verificar ejecuciones Múltiples frameworks: FakeItEasy, MoQ, NSubstitute, ( RhinoMocks, Autofac ) 18

19 Demo: sustitución con mocks Prueba de comportamiento con mocks Las pruebas no resuelven todo Cobertura de las pruebas Otros orígenes de los defectos del software 19

20 Cobertura de las pruebas Es imposible probar completamente todo el software, y en todas las circunstancias posibles. Se puede medir hasta cierto punto: Cobertura de funciones Cobertura de sentencias Cobertura 100% de sentencias no significa que el software funcione bien Cobertura de código Ejecutado Parcialmente ejecutado No ejecutado 20

21 Citando a Dijkstra Program testing can be used to show the presence of bugs, but never to show their absence! Citando a Dijkstra Las pruebas de programas se pueden usar para mostrar la presencia de bugs, pero nunca para mostrar su ausencia! 21

22 Orígenes de defectos de software No todos los problemas del software son bugs, pueden ser otros: Motivos técnicos: el software falla más tarde por el entorno, configuración de seguridad, rendimiento que no son requisitos (Cada vez hay más herramientas para probarlos) El cliente no sabe lo que quiere o lo explica mal Hemos visto Clasificación de las pruebas Coste y ventajas de las pruebas Ejecución de las pruebas automáticas Sustitutos Verificación de estados y comportamiento Las pruebas no resuelven todo Consejo final: probar, probar y probar! 22

23 Más Información Información ampliada sobre licencias, qué incluye cada edición, y utilidades software en: Información ampliada sobre formación, consultoría y cesión profesionales en: Valor añadido a la comunidad en forma de eventos como este, artículos técnicos o revistas en: +50 vídeos en castellano sobre Visual Studio, SQL Server, TFS y soluciones Microsoft en: shop.danysoft.com /servicios /comunidad /danysoftech Gracias Para más información contacta con Danysoft info@danysoft.com