Post on 23-Apr-2020
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