12/05/2015

1

Pruebas en Visual StudioXII Encuentro Danysoft en Microsoft | Directos al código

Jorge Bustos | Servicios Profesionalessp@danysoft.com | 916 638683 | www.danysoft.com Abril 2015

DíaTFS

Introducción a las pruebas Ejecución de pruebas en

Visual Studio Las pruebas no resuelven todo

12/05/2015

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ámicasPruebas estáticas:Sin ejecución de códigoDinámicas:Con ejecución de código

12/05/2015

3

Variación del algoritmo de Dijkstra(1959)

Edsger W. Dijkstra11/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

12/05/2015

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 cajanegra”

12/05/2015

5

¿Y si comprobamosque Suma(1,1) = 2?

public class Calculadora

{

public int Suma (int a, int b)

{

}

}

return 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

12/05/2015

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 (malditosubconsciente)

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…

12/05/2015

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

UnitariasUnitarias

IntegraciónIntegración

IUIUEjecución lenta

Amplio alcance

Menos pruebas

Alcance limitado

Más pruebasEjecución rápida

Más estables

Más inestables

12/05/2015

8

Pruebas en el ciclo de desarrollo

TDD Integración continuaPrueba continuaBDD

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”

12/05/2015

9

Citando a Dijkstra“… si la responsabilidad del programador no es sólo producir un programa correcto, sinotambién demostrar su corrección de unamanera convincente, […] esto tiene unaprofunda influencia en su actividad: el objetoque 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

12/05/2015

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 implementarProbar exhaustivamente las partes más usadas, más críticas y más complicadas

Pruebas manuales y automáticasManuales: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

12/05/2015

11

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

Ejecución de pruebas en Visual Studio

Todo el mundo prueba sus programas Prueba: cualquier cosa que hacemos para

comprobar que un programa funciona correctamente, e incluye:

Thechapuzero’sway

12/05/2015

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/05/2015

13

Fases de las pruebas

AAA: ArrangeActAssert

4 fases:SetupExerciseVerifyTear-down

Definición y ejecución de pruebasElegir un framework para definir las

pruebas: MSTest, NUnit, xUnit, Jasmine, QUnit…Ejecutar las pruebas: Test Runner de

Visual Studio, adaptador, test runnerexternos, en procesos de CI...

12/05/2015

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);

}

}

12/05/2015

15

Prueba unitaria frente aprueba 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)

12/05/2015

16

Ejemplo de dependencias

GestorVentas

Notificador

PasarelaPago

Almacen

Servidor email

Servidorpagos

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)

12/05/2015

17

Demo: prueba integración

Prueba de integración

Estilos de pruebas unitarias Verificación de estadoEstablece estado inicial, actúa, comprueba

estado final Verificación de comportamientoEjecuta prueba y verifica que se han

realizado las llamadas esperadas a las dependencias

12/05/2015

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 comportamientosPermiten verificar ejecuciones

Múltiples frameworks: FakeItEasy, MoQ, NSubstitute, ( RhinoMocks, Autofac…)

12/05/2015

19

Demo: sustitución con mocks

Prueba de comportamiento con mocks

Cobertura de las pruebasOtros orígenes de los defectos del

software

Las pruebas no resuelven todo

12/05/2015

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ódigoEjecutado

No ejecutado

Parcialmente ejecutado

12/05/2015

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!”

12/05/2015

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(Cadavezhaymásherramientasparaprobarlos)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!

12/05/2015

23

Más InformaciónInformación ampliada sobre licencias, qué incluye cada edición, y utilida-des software en:

shop.danysoft.com

Información ampliada sobre formación, consultoría y cesión profesionales en:

www.danysoft.com/servicios

Valor añadido a la comunidad en forma de eventos como este, artículos técnicos o revistas… en:

www.danysoft.com/comunidad

+50 vídeos en castellano sobre Visual Studio, SQL Server, TFS y soluciones Microsoft en:

www.youtube/danysoftech

GraciasPara más información contacta con Danysoft info@danysoft.com | www.danysoft.com | 916 638683