pruebas_intro.md

# Pruebas

-----------------

## Introduccion

'80 , c++ std de la industria. libro de "meyers?" se establece como estandar de pruebas.

Usualmente no se habla de pruebas sino de heramientas / fwks para pruebas.

Hacer pruebas:
* proceso p demostrar q el programa no tiene errores -> imposible x # de estados q tiene un pgm.
* demostrar q un pgm realiza las funcs para las cuales fue construido.
* ejecucion de pgms con el objeto de detectar defectos y fallas -> Meyers : proceso destructivo y "sadico" :
  - El q escribe el test debe hacerlo con el proposito de ROMPER el pgm a testear.

test exitoso : aquel que detecta errores
test No exitoso : aquel que no los detecta

un desa debe participar de pruebas de SU software? si, debe hacerlo. requiere un cambio de actitud que nos lleve a querer romper nuestro pgm. _naturalmente somos constructivos_.


## Filosof y econom

Tiempo para hacer pruebas es un tiempo q esta incluido en la planif del proyecto

Invertir tiempo y $ en pruebas aumenta revenue del proyecto al largo plazo

Cuanto mas tarde detecto fallas mas caro me resulta resolverlas.

Reqs -> diseno -> codif -> pruebas -> mantenim
$	$$	  $$$	   $$$$	      $$$$$

Microsoft es un caso raro. Liberan sus productos tempranamente plagados de errores y luego hacen mantenimiento. Teniendo el mercado cautivo, podian darse el lujo de hacer esto.


## Principios

Antiguamente se hacia TOODO el pgm y luego se hacian pruebas , esto lleva a deteccion tardia de fallas.

1. definir resultados esperados
2. un programador debe evitar probar su desarrollo
3. una org no debe probar sus propios desarrollos
4. revisar resultados de tests en profundidad
5. incluir entradas VALIDAS , INVALIDAS , ESPERADAS Y NO ESPERADAS
6. comprobar q el pgm no haga lo q NO SE ESPERA
7. no tirar los tests _a la basura_ (tests repetitivos  , regresion)
8. no plantear esfuerzos de pruebas asumiendo q no se encontraran errores
9. % de encontrar errores en una seccion de un pgm es proporcional al # de errores ya encontrados en esa seccion.
10. testing es una tarea creativa e intelectualmente desafiante


## niveles de pruebas

* unitario : prueba del programador
* integracion : busca detectar fallas en la integracion de dos programas desarrollados x separado
* funcional : busca detectar errores en la implementacion de requerimientos. Queremos verificar que se cumplan los casos de uso. Cada caso de uso amerita a ser probado x un caso de prueba.
* sistema : mismas pruebas funcionales pero teniendo en cuenta los reqs no funcionales, es decir, teniendo en cuenta el ambiente de ejecucion.
* aceptacion : pruebas q acuerdo con el usuario para que el me acepte el proyecto como TERMINADO.

## tipos de pruebas

* facilidad
* volumen : probar con muchos datos
* estres : sobrecargar ambiente
* usabilidad
* seguridad
* velocidad
* fiabilidad
...


## ciclo de desarrollo y pruebas

Las pruebas del codigo y arq deben hacerse desde el inicio del proyecto.

Testers deberian trabajar con los desarrolladores en la definicion de la arq y diseno.

_Sacarle de las manos la tarea de ejecutar las pruebas a mano a los testers_. Automatizar la ejecucion de las pruebas lo mas posible.


## Pruebas de caja negra

Solo tengo acceso al sistema mediante sus inputs y outputs.

Es imposible probar todas las entradas posibles, entonces juego con __clases de equivalencia__. Divido las posibles entradas en
segmentos, y pruebo como entradas los segmentos.

Ej: si como input se aceptan numeros enteros, puedo crear clases equivalencia NUMEROS_VALIDOS (1 al 99) y NUMEROS_INVALIDOS (menor a uno y mayor a 99).

## Pruebas de caja blanca

tengo acceso al codigo.

Todos los caminos del codigo deben estar probados. Debemos tener pruebas q pasen x todas las bifurcaciones.

Si un if tiene 2 condiciones de entrada posibles (con un Or) , debemos probar todas las entradas al cuerpo del if.

Probar por
* caminos
* decisiones
* condiciones : hacemos pruebas con valores limites y sus alrededores (inmed. superior e inferior).

_Debemos establecer un criterio base al escribir los tests_ :
* caminos
* decisiones
* condiciones
* valores limite

## Criterios de completitud de pruebas

1. parar cuando se agoto el tiempo asignado (en la planificacion).
2. parar cuando los tests dan todos los resultados esperados.
3. Si no se detectan errores despues de N tiempo y todos los casos son OK entonces terminamos.

Regla usual: 50% del tiempo de codificacion se dedica a probar el codigo.


## Propiedades

1. Repetitivos : tengo q poder correrlos muchas veces facilmente. que sea repetitivo de forma __sistematica__, con poco esfuerzo.
2. Criterio de diseno basado en las pruebas.
3. Que nuestros tests sean __atomicos__: _que el test pruebe una sola cosa_. Queremos aislar las fuentes de error. _Un test q no sea atomico no detecta_.
4. Independientes : la secuencialidad no importa. los tests no deben afectarse entre si.


## Sistematizacion

Escenario de ejecucion de pruebas:
* Setup : Inicializo el SUT
* Exercise : Ejecuto cosas sobre el SUT
* Verify : obtener estado (del SUT) y compararlo con valores validos
* Teardown : libero recursos del SUT



Principios de sistematizacion:
* Escribir tests primero
* Diseñar para testeabilidad
* Comunique el intento para facilitar lectura y mantenimiento de los tests
* No modificar el SUT para correr alguna prueba en particular (para luego "dejarlo como estaba antes")
* Mantener los tests independientes
* Aislar el SUT
* Minimizar el codigo no probado
* Separar logica de prueba del codigo productivo
...


    SETUP--initialize->

    EXERCISE--call---->
                         <=>  SUT  <=>  DOC
    VERIFY<--getState-->

    TEARDOWN

_generar las condiciones iniciales debe ser facil de hacerlo_



Se puede utilizar herencia para crear subclases tipo prueba de clases de negocio.
Ejemplo:

    Foo
     ^
     |
    FooForTest

FooForTest tiene sobreescribe logica de Foo agregando contadores y demas para verificar las invocaciones a Foo.

Este es el principio del patron _espia_.



-----------------

## Glosario

pgm : programa
fwk : framework
sut : system under test
doc : dependent on component. Es un componente del cual el sut depende
fixture : condiciones del test