test double testing de software

7/24/2019 Test Double Testing de software

1/34

Testing de Software


2/34

Tercera Unidad:TCNICAS DE TESTING


3/34

Test DoubleEn la programacin orientada a objetos, los programadores y desarrolladores empletcnica llamada automated unit testing para mejorar la calidad del software.

Con frecuencia, el software de la versin final consiste en un complejo conjunto de procedimientos que interactan en conjunto para crear el resultado final.

En la automated unit testing, puede ser necesario el uso de objetos o procedimienty se comportan igual que sus homlogos de la liberacin prevista, pero en realidad simplificadas que reducen la complejidad y facilitan la prueba.

Una Test Double es un (meta) trmino genrico utilizado para estos objetos o proce


4/34

Tipos de Test DoubleGerard Meszaros identific varios trminos diferentes para lo que l llama dobles Usando su vocabulario, hay al menos cinco tipos de dobles de prueba:

Test stub: prueba (utilizado para proporcionar el cdigo probado con "entrada indirecta")

Mock object : (utilizado para la verificacin de "salida indirecta" del cdigo probado, definlas expectativas antes de que se ejecute el cdigo de la prueba)

Test Spy: prueba (que permita comprobar "la produccin indirecta" del cdigo probado, mafirmacin de las expectativas despus, sin haber definido las expectativas antes de que scdigo de la prueba)

Fake object: (utilizado como una implementacin ms sencilla, por ejemplo, usando una en memoria en los ensayos en vez de hacer el acceso de base de datos real)

Objeto ficticio (utilizado cuando se necesita un parmetro para el mtodo probado, pero tener que utilizar el parmetro)


5/34

3.1 MockingEn la programacin orientada a objetos se llaman objetos simulados (pseudoobjetoobject, objetos de pega) a los objetos que imitan el comportamiento de objetos reaforma controlada.

Se usan para probar a otros objetos en pruebas unitarias que esperan mensajes de particular para sus mtodos.

En los test de unidad, los objetos simulados se usan para simular el comportamientcomplejos cuando es imposible o impracticable usar al objeto real en la prueba.


6/34

Resuelve el problema del caso de objetos interdependientes, que para probar el prser usado un objeto no probado an, lo que invalida la prueba:

Los objetos simulados son muy simples de construir y devuelven un resultado deteimplementacin directa, independientemente de los complejos procesos o interaccobjeto real pueda tener.


7/34

CaractersticasLos objetos simulados se usan en lugar de objetos reales que tengan algunas de estcaractersticas:

Devuelven resultados no determinsticos (por ejemplo la hora o la temperatura)

Su estado es difcil de crear o reproducir (por ejemplo errores de conexin)

Es lento (por ejemplo el resultado de un clculo intensivo o una bsqueda en una BBDD)

El objeto todava no existe o su comportamiento puede cambiar.

Debera incluir atributos o mtodos exclusivamente para el testeo.

Los objetos simulados para imitar al objeto real deben imitar su misma interfaz.


8/34

Para que sirven los Mocks?Muchas veces se est trabajando en equipo, por ende mucho del cdigo impacta a otras

viceversa.

Viene la gran pregunta Como vamos a poder probarlo si nuestro cdigo necesita utilizatodava no estn disponibles?.

Es en este momento donde tiene sentido el uso de objetos mock.

Utilizaremos estos objetos en los proyectos de pruebas de manera que podamos probarcdigo simulando el comportamiento de objetos que todava no estn disponibles a travlos mocks.

Un mock deber implementar el mismo interfaz del objeto que queremos simular.

En la clase que define la prueba deberemos definir qu mtodos del objeto real queremel mock, indicando para cada uno de ellos cual es la respuesta esperada cuando reciba uparmetros predeterminados.


9/34

Esa respuesta debe ser la misma que esperamos que devuelva el objeto real cuando est

Al ejecutar la prueba, cuando el cdigo que queremos probar llame a un objeto que toddisponible y que hemos simulado con el mock, esa llamada ser interceptada por el oque hayamos definido y este devolver la respuesta que hayamos definido y que se debcorresponder con la que esperamos que sea devuelta por el objeto real cuando est con

La utilizacin de mocks nos permite independizar el desarrollo de unas partes de la solu

Podemos desarrollar una parte y verificar que funciona correctamente con independencde partes con las que tenga relacin.

De esta manera el responsable de cada parte de cdigo puede centrarse en probar que est desarrollando funcione correctamente con independencia del estado de otras partaplicacin con las que tenga relacin.

Al decir esto nos damos cuenta que estamos desacoplando grandes cosas en cosas mas cual nos resulta sumamente tiles a la hora de generar los test.


10/34

Cuando se hacen las pruebas de esta manera, usted est centrado en uno de los elesoftware, de ah la necesidad de algn tipo de almacn en nuestro ejemplo.

En los dos estilos de las pruebas que he mostrado anteriormente, el primer caso seobjeto de almacn real y el segundo utiliza un almacn simulacro, que por supuestoobjeto de almacn real.

El uso de mock es una manera de no utilizar un almacn real en la prueba, pero hayde objetos irreales utilizados en las pruebas de esta manera.


11/34

Se utilizan los nombres de dobles de riesgo usados en las pelculas:

Dummy objects u Objetos ficticios se pasan por all, pero nunca se utilizan realmente. Porslo son utilizadas para rellenar listas de parmetros.

Fake objects u Objetos falsos en realidad tienen implementaciones de trabajo, pero por lotoman algn atajo que los hace no aptos para la produccin (una base de datos en la membuen ejemplo).

Stubs proporcionan respuestas enlatadas a las llamadas realizadas durante la prueba, porresponden en absoluto a nada fuera de lo que est programado en la prueba.

Los Stubs tambin pueden registrar la informacin sobre las llamadas. Mocks son lo que estamos hablando aqu: objetos pre-programado con las expectativas q

especificacin de las llamadas que se espera recibir.


12/34

3.2. StubbingUn mtodo stub o simplemente stub en el desarrollo de software es un trozo de cpara sustituir a alguna otra funcionalidad de programacin.

Un stub puede simular el comportamiento del cdigo (por ejemplo, un procedimienmquina remota) existente o ser un sustituto temporal para el cdigo todava-a-serdesarrollado.

Los stubs son por lo tanto ms til en portabilidad, computacin distribuida, as comdesarrollo de software en general y pruebas.

se utilizan principalmente en el enfoque de arriba hacia abajo de las pruebas incremStubs son programas informticos que actan como reemplazo temporal por un mllamado y le dan el mismo resultado que el producto real o software.


13/34

Un ejemplo de un taln en pseudocdigo podra ser la siguiente:

BEGIN

Temperature = ThermometerRead(Outside)

IF Temperature > 40 THEN

PRINT "It's HOT!"

END IF

END

BEGIN ThermometerRead(Source insideOrOutside)

RETURN 28

END ThermometerRead


14/34

El pseudocdigo anterior utiliza la funcin ThermometerRead, que devuelve una te

Mientras ThermometerRead estara destinado a leer algn dispositivo hardware, escontiene el cdigo necesario.

As ThermometerRead en esencia, simula cualquier proceso, sin embargo, no devuvalor legal, permitiendo que el programa principal para este al menos parcialmente

Tambin tenga en cuenta que si bien acepta el parmetro de tipo Fuente, que detenecesita dentro o fuera de la temperatura, que no utiliza el valor real transcurrido (insideOrOutside) por la persona que llama en su lgica.


15/34

Un stub es una rutina que en realidad no hace otra cosa que declararse y los parm

acepta y devuelve, es por lo general los valores esperados en uno de los "escenariola llamada.

Los Stubs son comnmente utilizados como marcadores de posicin para la implemuna interfaz conocida, donde la interfaz est finalizado/conocido pero la implementse sabe/finalizado.

El trozo contiene suficiente cdigo para permitir que se compile y se enlace con el r

programa.

En la nomenclatura RMI, un stub se comunica en el lado del servidor con un esquel


16/34

3.3. Fake objectsSi ha estado escribiendo pruebas unitarias por un corto tiempo se dar cuenta de q

buenas pruebas unitarias es difcil.

El objeto a prueba puede ser difcil de crear, ya que requiere dependencias que ustesimplemente no puede proporcionar o se necesita algn entorno complicado slo ppase de prueba.

Al escribir una prueba unitaria uno de los desafos es cmo codificar en torno a lasdependencias del objeto de prueba.

En otras palabras - cmo aislar el cdigo bajo prueba de dependencias externas.


17/34

Un fake object es un Double Test con la lgica real (a diferencia de los stubs) y es m

simplificado o ms barato de alguna manera.

No usamos mock o stubs a una unidad que probamos; ms bien, las dependencias unidad son objetos mock o stubs de modo que la salida de los objetos dependientecontrolada u observada a partir de los test.

El objeto falso sustituye a la funcionalidad del cdigo real que queremos probar.

Los fakes son tambin dependencias, y no se hace mock a travs de subclases (quegeneralmente es siempre una mala idea, el uso de la composicin en su lugar).

Los fakes no slo se apag valores de retorno; que utilizan una lgica real.


18/34

Concepto: son objetos que reemplazan a otro objeto del sistema con una implemen

alternativa.

Por ejemplo, el reemplazo de una base de datos en disco por otra en memoria por desempeo.

Se utilizan ampliamente en el cdigo heredado. Las siguientes son las razones de usfalso:

El objeto real no puede ser instanciado, tal como cuando el constructor lee un archivo, rebsqueda JNDI, y as sucesivamente.

El objeto real tiene mtodos lentos; Por ejemplo, una clase puede tener un mtodo calcunecesita ser probado unitariamente, pero el mtodo calculate() llama a un mtodo load()recuperar datos de la base de datos.

El mtodo load () necesita una base de datos real, y se necesita tiempo para recuperar loque tenemos que pasar por alto el mtodo load () para la prueba unitaria del mtodo calc


19/34

Hay otras buenas razones para fingir un objeto:

Haga la prueba determinista - pruebas unitarias deben tener el mismo resultado cada vezejecuta. Si su objeto devuelve un valor no determinista que cambiar cada vez que se ejecfingiendo que el comportamiento de la clase se puede hacer volver el mismo valor cada v

Es difcil de configurar el entorno - si usted necesita una base de datos (con datos concretservidor o componentes similares para la prueba a pasar.

Cuando todava no existen objetos - durante el desarrollo no se puede confiar en todos lonecesita para ser cuando usted los necesita. Es posible que tenga otra clase que no fue esalgn algoritmo que no se ha implementado todava.

Difciles de reproducir el estado - E.C. es necesario comprobar qu sucede cuando el clienerror de red al llamar a su servidor.

Objetos falsos se utilizan para aislar su cdigo de dependencias externas. Usted puede es(llamada mano rod burla de / falsificaciones), pero no hay razn para reinventar la ruedade aislamiento para la mayora de los idiomas principales - y comprueba la lista de los maobjetos simulados de Wikipedia para su idioma de eleccin.


20/34

Qu puede hacer el framework deaislamiento por usted?Todos aislamiento (burlndose) marcos me encontr no los tres siguientes:

Crear objetos falsos

Establecer comportamiento del objeto falso

Verifique mtodo fue / no fue llamado

Algunos marcos tienen capacidades adicionales - dependiendo del lenguaje de programafuncionamiento interno (cmo funcionan).


21/34

IntroduccinTodos los programadores saben que deben realizar pruebas a su cdigo, pocos lo ha

manera proactiva, la respuesta generalizada al por qu no? es no tengo tiempo

Este apuro se convierte en un crculo vicioso.

Cuanta ms presin se siente, menos pruebas se realizan.

Cuantas menos pruebas se realizan, menos productivo se es y el cdigo se vuelve mestable.

Cuanto menos productivo y preciso se es, ms presin se siente.


22/34

Qu es una prueba unitaria?Una prueba unitaria, o unit test, es un mtodo que prueba una unidad estructura

Contrariamente a lo que piensan muchos desarrolladoresque el desarrollo de pruunitarias resta tiempo a tareas ms importante las pruebas unitarias por lo generay rpidas de codificar, el desarrollo de una prueba unitaria no debera tomar ms deminutos.


23/34

Debido a la diversidad de definiciones, convendremos que una buena prueba unit

siguientes caractersticas: Unitaria, prueba solamente pequeas cantidades de cdigo.

Independiente, no debe depender ni afectar a otras pruebas unitarias.

Prueba mtodos pblicos, de otra forma la prueba sera frgil a cambios en la implementpodra utilizar en pruebas de regresin.

Automatizable, la prueba no debera requerir intervencin manual.


24/34

Repetible y predecible, no debe incidir el orden y las veces que se repita la prueba, el resu

debe ser el mismo. Profesionales, las pruebas deben ser consideradas igual que el cdigo, con la misma profe

documentacin, etc.

Respecto al ltimo punto y contrariamente a lo que piensan muchos desarrolladoresqude pruebas unitarias resta tiempo a tareas ms importante las pruebas unitarias por lo gsimples y rpidas de codificar, el desarrollo de una prueba unitaria no debera tomar msminutos.


25/34

VentajasLas pruebas unitarias buscan aislar cada parte del programa y mostrar que las parte

individuales son correctas, proporcionando cinco ventajas bsicas: Fomentan el cambio, las pruebas unitarias facilitan la reestructuracin del cdigo (refacto

puesto que permiten hacer pruebas sobre los cambios y verificar que las modificaciones nintroducido errores (regresin).

Simplifican la integracin, permiten llegar a la fase de integracin asegurando que las parindividuales funcionan correctamente. De esta manera se facilitan las pruebas de integrac

Documentan el cdigo, las propias pruebas pueden considerarse documentacin, ya que una implementacin de referencia de como utilizar el cdigo.


26/34

Separacin de la interfaz y la implementacin, la nica interaccin entre los casos de prue

unidades bajo prueba son las interfaces de estas ltimas, se puede cambiar cualquiera deafectar al otro (ver pruebas mock).

Menos errores y ms fciles de localizar, las pruebas unitarias reducen la cantidad de errotiempo en localizarlos.


27/34

Pueden mejorar el diseo, la utilizacin de prcticas de diseo y desarrollo dirigida por la

Driven Development o TDD) permite definir el comportamiento esperado en un paso precodificacin.

Puede ser la forma ms simple de verificar el funcionamiento, en situaciones como el desAPI o un componente que brinda servicios del cual no se cuenta an con un cliente para c

Adoptar el uso de pruebas unitarias como una disciplina generalizada puede ser un trabapero no debe ser considerado una desventaja, debe entenderse que esta actividad nos seahorrar tiempo en el futuro al disminuir la ocurrencia de errores.

La utilizacin de pruebas unitarias permitir mejorar progresivamente la calidad del cdig

que los desarrolladores aumenten la calidad de las pruebas y la cobertura del mismo, porMicroGestion durante el ao 2011 se dedicaron 1160 horas a la resolucin de errores en desarrollo y en el perodo de garanta, y en 2012 se registraron 710 horas".


28/34

ConsideracionesComo en la adopcin de cualquier otra disciplina, la incorporacin de pruebas unitarias

exenta de problemas o limitaciones, a continuacin se enumeran algunas consideracioncuenta:

Por estar orientada a la prueba de fragmentos de cdigo aislados, la pruebas unitarias no descude integracin, problemas de rendimiento y otros problemas que afectan a todo el sistema en

En alguno casos ser complicado anticipar inicialmente cuales son los valores de entradas adecpruebas, en esos casos las pruebas debern evolucionar e ir incorporando valores de entrada r

Si la utilizacin de pruebas unitarias no se incorpora como parte de la metodologa de trabajo,probablemente, el cdigo quedar fuera de sincronismo con los casos de prueba.

Otro desafo es el desarrollo de casos de prueba realistas y tiles. Es necesario crear condicioneque la porcin de aplicacin que est siendo probada funcione como parte completa del sistempertenece.

Escribir cdigo para un caso de pruebas unitario tiene tantas probabilidades de estar libre de emismo cdigo que se est probando.


29/34

Pruebas utilizando objetos simulado(mock)Las pruebas Mock son pruebas unitarias que utilizan objetos simulados ("mock") que sustituyen a

reales utilizados por la clase o fragmento de cdigo a probar.Por ejemplo, se tiene una clase Calculator que necesita de un DAO (Objeto de Acceso a Datos) parinformacin de la base de datos, este DAO es lo que llamamos el objeto real. Si quisiramos realde la clase Calculator, deberamos pasarle al objeto una conexin vlida a la base de datos y asegulos datos que necesita existan.

Este proceso de determinar los datos que el objeto necesita e insertarlos en la base requiere de m

En lugar de esto, se puede proveer una instancia falsa del DAO que slo devuelva lo que necesitamprueba. Esta clase no va a tomar la informacin de la base de datos, sino que va a ser un mock.

Reemplazar el objeto real hace que probar la clase Calculator sea mucho ms simple. Estrictamendicho objeto que reemplaza al DAO real no sera un mock, sino un stub. Luego hablaremos de esta

Este ejemplo puntual de la clase Calculator se puede generalizar diciendo que es una unidad (Calcutilizando un colaborador (DAO).


30/34

Unidad Colaborador

Nota: la flecha significa usa.

Cuando reemplazamos al colaborador por un mock (o stub), esto se puede expresar de la siguiente manera:

Unidad Mock

En el contexto de una prueba unitaria se vera de la siguiente manera:

Prueba Unitaria Unidad Colaborador

Prueba Unitaria Unidad Mock


31/34

Utilizacin de stub, mock y proxy

Hay tres tipo de objetos falsos que se pueden usar para reemplazar a los objetos copara realizar pruebas unitarias: stub, mock y proxy.

Objetos stub

Un stub es un objeto que implementa una interface de un componente, pero en lug

retornar lo que el componente devolvera, el stub puede ser configurado para retorque se ajuste a lo que la prueba unitaria intenta probar.

Utilizando este tipo de objetos se puede probar si una unidad es capaz de manejar valores devueltos por el colaborador. Esto se puede expresar de la siguiente manera


32/34

1. Prueba Unitaria Stub

2. Prueba Unitaria Unidad Stub

3. La prueba unitaria verifica (assert) sobre el resultado y el estado de la unidad

El primer paso de la prueba unitaria es crear el objeto stub y configurar los valores (1).

Luego se crea la unidad y se le setea el stub en lugar del colaborador real (2).

Por ltimo se verifica el resultado de la llamada a la unidad (3).

Ejemplo utilizando objetos stub (pseudocdigo)


33/34

El TDD (Test Drive development), desarrollo conducido por pruebas, donde la fuerza

programas se basa justo en eso, en los test de las clases que vamos generando (De propone generar los test antes de crear el cdigo de la clase).

Para poder crear un buen conjunto de pruebas unitarias, es necesario que nos centexclusivamente en la clase a testear, simulando el funcionamiento de las capas infe

De esta manera estaremos creando test unitarios potentes que os permitira detectsolucionar los errores que tengis o que se cometan durante el futuro del desarrolloaplicacin.


34/34

Para esta tarea nos apoyaremos en el uso de mock objects, que no son ms que ob

simulan parte del comportamiento de una clase.

test double testing de software

Documents