técnicas de programación
Post on 05-Dec-2014
183 Views
Preview:
DESCRIPTION
TRANSCRIPT
Tecnicas avanzadas de programacion. . . o como hacer software sin morir en el intento
Jose Luis Diaz
26 de junio de 2014
Jose Luis Diaz 26 de junio de 2014 1 / 80
Principios de diseno
Agenda
1 Principios de disenoOcultacion de la informacionHacia los objetos
2 SOLIDSingle responsibility principleOpen-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle
3 TestingTest First DevelopmentTecnicas de testingDependencias
Jose Luis Diaz 26 de junio de 2014 2 / 80
Principios de diseno Ocultacion de la informacion
Agenda
1 Principios de disenoOcultacion de la informacionHacia los objetos
2 SOLIDSingle responsibility principleOpen-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle
3 TestingTest First DevelopmentTecnicas de testingDependencias
Jose Luis Diaz 26 de junio de 2014 3 / 80
Principios de diseno Ocultacion de la informacion
Diseno
¿Por que disenar?
Incorporar nuevos requerimientos evitando que el diseno se degrade.
Los cambios puedan incorporarse con el menor costo posible.
Hacer el caso comun facil, el caso complejo posible (Joshua Bloshsobre los lenguajes)
Jose Luis Diaz 26 de junio de 2014 4 / 80
Principios de diseno Ocultacion de la informacion
Diseno
¿Por que disenar?
Incorporar nuevos requerimientos evitando que el diseno se degrade.
Los cambios puedan incorporarse con el menor costo posible.
Hacer el caso comun facil, el caso complejo posible (Joshua Bloshsobre los lenguajes)
Jose Luis Diaz 26 de junio de 2014 4 / 80
Principios de diseno Ocultacion de la informacion
Diseno
¿Por que disenar?
Incorporar nuevos requerimientos evitando que el diseno se degrade.
Los cambios puedan incorporarse con el menor costo posible.
Hacer el caso comun facil, el caso complejo posible (Joshua Bloshsobre los lenguajes)
Jose Luis Diaz 26 de junio de 2014 4 / 80
Principios de diseno Ocultacion de la informacion
Diseno
¿Por que disenar?
Incorporar nuevos requerimientos evitando que el diseno se degrade.
Los cambios puedan incorporarse con el menor costo posible.
Hacer el caso comun facil, el caso complejo posible (Joshua Bloshsobre los lenguajes)
Jose Luis Diaz 26 de junio de 2014 4 / 80
Principios de diseno Ocultacion de la informacion
Parnas
Una metodologıa para componentizar (Parnas, David a principio de los ’70)
Identificar potenciales componentes. Detectar desde losrequerimientos los que mas vayan a cambiar.
Se contraen y expanden los requerimientos de estos componentes.
Aislar estos componentes y generar interfaces que toleren estoscambios anticipados.
Jose Luis Diaz 26 de junio de 2014 5 / 80
Principios de diseno Ocultacion de la informacion
Parnas
Una metodologıa para componentizar (Parnas, David a principio de los ’70)
Identificar potenciales componentes. Detectar desde losrequerimientos los que mas vayan a cambiar.
Se contraen y expanden los requerimientos de estos componentes.
Aislar estos componentes y generar interfaces que toleren estoscambios anticipados.
Jose Luis Diaz 26 de junio de 2014 5 / 80
Principios de diseno Ocultacion de la informacion
Parnas
Una metodologıa para componentizar (Parnas, David a principio de los ’70)
Identificar potenciales componentes. Detectar desde losrequerimientos los que mas vayan a cambiar.
Se contraen y expanden los requerimientos de estos componentes.
Aislar estos componentes y generar interfaces que toleren estoscambios anticipados.
Jose Luis Diaz 26 de junio de 2014 5 / 80
Principios de diseno Ocultacion de la informacion
Parnas
Una metodologıa para componentizar (Parnas, David a principio de los ’70)
Identificar potenciales componentes. Detectar desde losrequerimientos los que mas vayan a cambiar.
Se contraen y expanden los requerimientos de estos componentes.
Aislar estos componentes y generar interfaces que toleren estoscambios anticipados.
Jose Luis Diaz 26 de junio de 2014 5 / 80
Principios de diseno Hacia los objetos
Agenda
1 Principios de disenoOcultacion de la informacionHacia los objetos
2 SOLIDSingle responsibility principleOpen-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle
3 TestingTest First DevelopmentTecnicas de testingDependencias
Jose Luis Diaz 26 de junio de 2014 6 / 80
Principios de diseno Hacia los objetos
Limitaciones
Limitaciones del diseno basado en ocultacion de informacion.
Incluir todos los metodos de la interfaz de un modulo correspondientecomo un parametro.
Generar varios modulos iguales.
Poder tener varias implementaciones diferentes de un mismo moduloy poder intercambiarlos.
Jose Luis Diaz 26 de junio de 2014 7 / 80
Principios de diseno Hacia los objetos
Limitaciones
Limitaciones del diseno basado en ocultacion de informacion.
Incluir todos los metodos de la interfaz de un modulo correspondientecomo un parametro.
Generar varios modulos iguales.
Poder tener varias implementaciones diferentes de un mismo moduloy poder intercambiarlos.
Jose Luis Diaz 26 de junio de 2014 7 / 80
Principios de diseno Hacia los objetos
Limitaciones
Limitaciones del diseno basado en ocultacion de informacion.
Incluir todos los metodos de la interfaz de un modulo correspondientecomo un parametro.
Generar varios modulos iguales.
Poder tener varias implementaciones diferentes de un mismo moduloy poder intercambiarlos.
Jose Luis Diaz 26 de junio de 2014 7 / 80
Principios de diseno Hacia los objetos
Limitaciones
Limitaciones del diseno basado en ocultacion de informacion.
Incluir todos los metodos de la interfaz de un modulo correspondientecomo un parametro.
Generar varios modulos iguales.
Poder tener varias implementaciones diferentes de un mismo moduloy poder intercambiarlos.
Jose Luis Diaz 26 de junio de 2014 7 / 80
SOLID
Agenda
1 Principios de disenoOcultacion de la informacionHacia los objetos
2 SOLIDSingle responsibility principleOpen-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle
3 TestingTest First DevelopmentTecnicas de testingDependencias
Jose Luis Diaz 26 de junio de 2014 8 / 80
SOLID Single responsibility principle
Agenda
1 Principios de disenoOcultacion de la informacionHacia los objetos
2 SOLIDSingle responsibility principleOpen-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle
3 TestingTest First DevelopmentTecnicas de testingDependencias
Jose Luis Diaz 26 de junio de 2014 9 / 80
SOLID Single responsibility principle
Cada clase debe tener una unica responsabilidad, y que esta debe sercompletamente ocultada por la clase (o modulo).
Este principio fue originalmente descripto como “cohesion”, larelacion funcional de los elementos de una clase.
Jose Luis Diaz 26 de junio de 2014 10 / 80
SOLID Single responsibility principle
Cada clase debe tener una unica responsabilidad, y que esta debe sercompletamente ocultada por la clase (o modulo).
Este principio fue originalmente descripto como “cohesion”, larelacion funcional de los elementos de una clase.
Jose Luis Diaz 26 de junio de 2014 10 / 80
SOLID Single responsibility principle
¿Por que es importante este principio?
Si una clase tiene mas de una responsabilidad, entonces lasresponsabilidades estan acopladas.
Los cambios en una de las responsabilidades pueden alterar o inhibirla capacidad de la clase para cumplir con las otras.
Este tipo de acoplamiento conduce a disenos fragiles que se rompende manera inesperada cuando las clases cambian.
Jose Luis Diaz 26 de junio de 2014 11 / 80
SOLID Single responsibility principle
¿Por que es importante este principio?
Si una clase tiene mas de una responsabilidad, entonces lasresponsabilidades estan acopladas.
Los cambios en una de las responsabilidades pueden alterar o inhibirla capacidad de la clase para cumplir con las otras.
Este tipo de acoplamiento conduce a disenos fragiles que se rompende manera inesperada cuando las clases cambian.
Jose Luis Diaz 26 de junio de 2014 11 / 80
SOLID Single responsibility principle
¿Por que es importante este principio?
Si una clase tiene mas de una responsabilidad, entonces lasresponsabilidades estan acopladas.
Los cambios en una de las responsabilidades pueden alterar o inhibirla capacidad de la clase para cumplir con las otras.
Este tipo de acoplamiento conduce a disenos fragiles que se rompende manera inesperada cuando las clases cambian.
Jose Luis Diaz 26 de junio de 2014 11 / 80
SOLID Single responsibility principle
¿Por que es importante este principio?
Si una clase tiene mas de una responsabilidad, entonces lasresponsabilidades estan acopladas.
Los cambios en una de las responsabilidades pueden alterar o inhibirla capacidad de la clase para cumplir con las otras.
Este tipo de acoplamiento conduce a disenos fragiles que se rompende manera inesperada cuando las clases cambian.
Jose Luis Diaz 26 de junio de 2014 11 / 80
SOLID Single responsibility principle
Aplicación de geometría
computacionalAplicación gráfica
GUI
Rectángulo
+ dibujar()+ area(): double
Jose Luis Diaz 26 de junio de 2014 12 / 80
SOLID Single responsibility principle
Aplicación de geometría
computacionalAplicación gráficaGUI
Rectángulo
+ dibujar()
RectánguloGeométrico
+ area(): double
Jose Luis Diaz 26 de junio de 2014 13 / 80
SOLID Open-closed principle
Agenda
1 Principios de disenoOcultacion de la informacionHacia los objetos
2 SOLIDSingle responsibility principleOpen-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle
3 TestingTest First DevelopmentTecnicas de testingDependencias
Jose Luis Diaz 26 de junio de 2014 14 / 80
SOLID Open-closed principle
Open-closed principle
Primera ves enunciada por Ivar Jacobson y luego reexpresada porBertran Meyer en “Object Oriented Software Construction”:
“Las entidades de software (clases, modulos, funciones, etc). Debenestar abiertas para extension, pero cerradas para modificacion”
Esforzarse para hacer que cuando el codigo cambie, solo lugar en unlugar.
Jose Luis Diaz 26 de junio de 2014 15 / 80
SOLID Open-closed principle
Open-closed principle
Primera ves enunciada por Ivar Jacobson y luego reexpresada porBertran Meyer en “Object Oriented Software Construction”:
“Las entidades de software (clases, modulos, funciones, etc). Debenestar abiertas para extension, pero cerradas para modificacion”
Esforzarse para hacer que cuando el codigo cambie, solo lugar en unlugar.
Jose Luis Diaz 26 de junio de 2014 15 / 80
SOLID Open-closed principle
1 class Cuadrado { public double lado; }2 class Circle { public double radio; }3
4 class GUI {5 Object[] figuras;6
7 public void refresh() {8 for (Object figura: figuras) {9 if (figura instanceof Cuadrado) {
10 dibujarCuadrado(((Cuadrado) figura).lado);11 }12 else if (figura instanceof Circle) {13 dibujarCirculo(((Circle) figura).radio);14 }15 }16 }17
18 private void dibujarCirculo(double radio) {}19 private void dibujarCuadrado(double lado) {}20 }
Jose Luis Diaz 26 de junio de 2014 16 / 80
SOLID Open-closed principle
1 interface Dibujable { public void dibujar(); }2 class Cuadrado implements Dibujable { public double lado; }3
4 class Circle implements Dibujable { public double radio; }5
6 class GUI {7 List<Dibujable> figuras;8
9 public void refresh() {10 for (Dibujable figura: figuras) {11 figura.dibujar()12 }13 }14
15 }
Jose Luis Diaz 26 de junio de 2014 17 / 80
SOLID Liskov substitution principle
Agenda
1 Principios de disenoOcultacion de la informacionHacia los objetos
2 SOLIDSingle responsibility principleOpen-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle
3 TestingTest First DevelopmentTecnicas de testingDependencias
Jose Luis Diaz 26 de junio de 2014 18 / 80
SOLID Liskov substitution principle
Liskov substitution principle
Propiedad
Propiedad de sustitucion: Si para cada objeto o1 de tipo S hay un objetoo2 de tipo T tal que: para todo programa P que se define en terminos deT, el comportamiento de P no varia cuando o1 es sustituido por o2entonces S es un subtipo de T.
Jose Luis Diaz 26 de junio de 2014 19 / 80
SOLID Liskov substitution principle
Una clara violacion del principio:
1 void dibujar(Figura f) {2 if (figura instanceof Cuadrado) {3 dibujarCuadrado(((Cuadrado) figura).lado);4 }5 else if (figura instanceof Circle) {6 dibujarCirculo(((Circle) figura).radio);7 }8 }
Jose Luis Diaz 26 de junio de 2014 20 / 80
SOLID Liskov substitution principle
El array en Java es covariante
1 String[] strings = new String[1];2 Object[] objects = strings;3 objects[0] = 1; // WAT!
Las Listas son invariantes.
4 List<String> ys = new LinkedList<String>();5 ys.add("zero"); ys.add("one");6 List<Object> a = yy // Error compilando7 String y = ys.iterator().next();
Jose Luis Diaz 26 de junio de 2014 20 / 80
SOLID Interface segregation principle
Agenda
1 Principios de disenoOcultacion de la informacionHacia los objetos
2 SOLIDSingle responsibility principleOpen-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle
3 TestingTest First DevelopmentTecnicas de testingDependencias
Jose Luis Diaz 26 de junio de 2014 21 / 80
SOLID Interface segregation principle
Interface segregation principle
Propiedad
Ningun cliente tiene que ser forzado a depender de metodos que no utiliza.
Jose Luis Diaz 26 de junio de 2014 22 / 80
SOLID Interface segregation principle
1 interface Door {2 public void lock();3 public void unlock();4 public boolean isDoorOpen();5 }6
7 class Timer {8 public void Regsiter(int timeout, TimerClient client) {}9 }
10
11 interface TimerClient {12 public void timeOut();13 }
Jose Luis Diaz 26 de junio de 2014 23 / 80
SOLID Interface segregation principle
TimerClient
Door TimedDoor
Jose Luis Diaz 26 de junio de 2014 24 / 80
SOLID Interface segregation principle
Door
TimedDoor DoorTimerAdapter
TimerClient
Jose Luis Diaz 26 de junio de 2014 25 / 80
SOLID Interface segregation principle
1 class TimedDoor extends Door {2 void doorTimeOut() { }3 }4
5 class DoorTimerAdapter implements TimerClient {6
7 private TimedDoor timedDoor;8
9 public DoorTimerAdapter(TimedDoor door) {10
11 }12
13 void TimeOut(int timeOutId) {14 timedDoor.doorTimeOut();15 }16
17 }
Jose Luis Diaz 26 de junio de 2014 26 / 80
SOLID Dependency inversion principle
Agenda
1 Principios de disenoOcultacion de la informacionHacia los objetos
2 SOLIDSingle responsibility principleOpen-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle
3 TestingTest First DevelopmentTecnicas de testingDependencias
Jose Luis Diaz 26 de junio de 2014 27 / 80
SOLID Dependency inversion principle
Dependency inversion principle
Propiedad
Deberıamos depender de Abstracciones y no de implenentaciones.
Jose Luis Diaz 26 de junio de 2014 28 / 80
SOLID Dependency inversion principle
Dependency inversion principle
Cuando disenamos una API, usualmente lo hacemos pensando en loque la API necesita
Cuando en realidad deberıamos pensar lo que el cliente necesita
Esto invierte la dependencia
Jose Luis Diaz 26 de junio de 2014 29 / 80
SOLID Dependency inversion principle
Dependency inversion principle
Cuando disenamos una API, usualmente lo hacemos pensando en loque la API necesita
Cuando en realidad deberıamos pensar lo que el cliente necesita
Esto invierte la dependencia
Jose Luis Diaz 26 de junio de 2014 29 / 80
SOLID Dependency inversion principle
Dependency inversion principle
Cuando disenamos una API, usualmente lo hacemos pensando en loque la API necesita
Cuando en realidad deberıamos pensar lo que el cliente necesita
Esto invierte la dependencia
Jose Luis Diaz 26 de junio de 2014 29 / 80
Testing
Agenda
1 Principios de disenoOcultacion de la informacionHacia los objetos
2 SOLIDSingle responsibility principleOpen-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle
3 TestingTest First DevelopmentTecnicas de testingDependencias
Jose Luis Diaz 26 de junio de 2014 30 / 80
Testing Test First Development
Agenda
1 Principios de disenoOcultacion de la informacionHacia los objetos
2 SOLIDSingle responsibility principleOpen-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle
3 TestingTest First DevelopmentTecnicas de testingDependencias
Jose Luis Diaz 26 de junio de 2014 31 / 80
Testing Test First Development
Tipos de Tests
Unit Test: Prueba clases y metodos, usualmente corren rapido yayudan a aislar cuando un error ocurre
Integration Test: Prueba el comportamiento de componentes, y susdependencias.
System Test: Prueba el sistema entero.
Jose Luis Diaz 26 de junio de 2014 32 / 80
Testing Test First Development
Tipos de Tests
Unit Test: Prueba clases y metodos, usualmente corren rapido yayudan a aislar cuando un error ocurre
Integration Test: Prueba el comportamiento de componentes, y susdependencias.
System Test: Prueba el sistema entero.
Jose Luis Diaz 26 de junio de 2014 32 / 80
Testing Test First Development
Tipos de Tests
Unit Test: Prueba clases y metodos, usualmente corren rapido yayudan a aislar cuando un error ocurre
Integration Test: Prueba el comportamiento de componentes, y susdependencias.
System Test: Prueba el sistema entero.
Jose Luis Diaz 26 de junio de 2014 32 / 80
Testing Test First Development
Que es TDD?
Test Driven Development no es una metodologıa de test
Test Driven Development es una metodologıa de diseno
No deja de lado el uso de QA, pero ayuda!
Jose Luis Diaz 26 de junio de 2014 33 / 80
Testing Test First Development
Que es TDD?
Test Driven Development no es una metodologıa de test
Test Driven Development es una metodologıa de diseno
No deja de lado el uso de QA, pero ayuda!
Jose Luis Diaz 26 de junio de 2014 33 / 80
Testing Test First Development
Que es TDD?
Test Driven Development no es una metodologıa de test
Test Driven Development es una metodologıa de diseno
No deja de lado el uso de QA, pero ayuda!
Jose Luis Diaz 26 de junio de 2014 33 / 80
Testing Test First Development
Test Driven es Test First
TDD significa diferentes cosas para diferentes personas.
Para nosotros, significa primero Testear
Jose Luis Diaz 26 de junio de 2014 34 / 80
Testing Test First Development
Test Driven es Test First
TDD significa diferentes cosas para diferentes personas.
Para nosotros, significa primero Testear
Jose Luis Diaz 26 de junio de 2014 34 / 80
Testing Test First Development
¿Testear primero o al final?
Si escribimos los Tests al principio ganamos algo de valor en cadapaso.
Si escribimos los Tests al final, solo tenemos buenas noticias o malasnoticias.
Jose Luis Diaz 26 de junio de 2014 35 / 80
Testing Test First Development
¿Testear primero o al final?
Si escribimos los Tests al principio ganamos algo de valor en cadapaso.
Si escribimos los Tests al final, solo tenemos buenas noticias o malasnoticias.
Jose Luis Diaz 26 de junio de 2014 35 / 80
Testing Test First Development
¿Como puede ser mas rapido?
Cada clase que se utilice produccion tiene una clase de Test
Cada metodo que se utilice en produccion tiene un metodo de Test
¿Como escribir mas codigo puede ser mas rapido?
Jose Luis Diaz 26 de junio de 2014 36 / 80
Testing Test First Development
¿Como puede ser mas rapido?
Cada clase que se utilice produccion tiene una clase de Test
Cada metodo que se utilice en produccion tiene un metodo de Test
¿Como escribir mas codigo puede ser mas rapido?
Jose Luis Diaz 26 de junio de 2014 36 / 80
Testing Test First Development
¿Como puede ser mas rapido?
Cada clase que se utilice produccion tiene una clase de Test
Cada metodo que se utilice en produccion tiene un metodo de Test
¿Como escribir mas codigo puede ser mas rapido?
Jose Luis Diaz 26 de junio de 2014 36 / 80
Testing Test First Development
¿Que dejamos de hacer?
se vuelven una forma de requerimientos, dejamos de pasar tiempoescribiendo documentos de requerimientos
nos ayudan a encontrar bugs mas rapido, pasamos menos tiempo enel debugger
nos ayudan a integrar codigo, pasamos menos tiempo integrandocodigo
nos dan energıa y confianza
Jose Luis Diaz 26 de junio de 2014 37 / 80
Testing Test First Development
¿Que dejamos de hacer?
se vuelven una forma de requerimientos, dejamos de pasar tiempoescribiendo documentos de requerimientos
nos ayudan a encontrar bugs mas rapido, pasamos menos tiempo enel debugger
nos ayudan a integrar codigo, pasamos menos tiempo integrandocodigo
nos dan energıa y confianza
Jose Luis Diaz 26 de junio de 2014 37 / 80
Testing Test First Development
¿Que dejamos de hacer?
se vuelven una forma de requerimientos, dejamos de pasar tiempoescribiendo documentos de requerimientos
nos ayudan a encontrar bugs mas rapido, pasamos menos tiempo enel debugger
nos ayudan a integrar codigo, pasamos menos tiempo integrandocodigo
nos dan energıa y confianza
Jose Luis Diaz 26 de junio de 2014 37 / 80
Testing Test First Development
¿Que dejamos de hacer?
se vuelven una forma de requerimientos, dejamos de pasar tiempoescribiendo documentos de requerimientos
nos ayudan a encontrar bugs mas rapido, pasamos menos tiempo enel debugger
nos ayudan a integrar codigo, pasamos menos tiempo integrandocodigo
nos dan energıa y confianza
Jose Luis Diaz 26 de junio de 2014 37 / 80
Testing Test First Development
Primero testear
Escribir test puede ser incomodo al principio
Con la practica se vuelve mucho mas facil
Nos ayuda a disenar lo que queremos construir
Jose Luis Diaz 26 de junio de 2014 38 / 80
Testing Test First Development
Primero testear
Escribir test puede ser incomodo al principio
Con la practica se vuelve mucho mas facil
Nos ayuda a disenar lo que queremos construir
Jose Luis Diaz 26 de junio de 2014 38 / 80
Testing Test First Development
Primero testear
Escribir test puede ser incomodo al principio
Con la practica se vuelve mucho mas facil
Nos ayuda a disenar lo que queremos construir
Jose Luis Diaz 26 de junio de 2014 38 / 80
Testing Test First Development
Lento mas que rapido
Aprender algo nuevo siempre es difıcil al principio
Una vez que uno se vuelve bueno, se vuelve mucho mas rapido
Equipos usando TDD reportan un incremento de un 2050 % develocidad y un 80 % de reduccion de defectos el primer ano
Jose Luis Diaz 26 de junio de 2014 39 / 80
Testing Test First Development
Lento mas que rapido
Aprender algo nuevo siempre es difıcil al principio
Una vez que uno se vuelve bueno, se vuelve mucho mas rapido
Equipos usando TDD reportan un incremento de un 2050 % develocidad y un 80 % de reduccion de defectos el primer ano
Jose Luis Diaz 26 de junio de 2014 39 / 80
Testing Test First Development
Lento mas que rapido
Aprender algo nuevo siempre es difıcil al principio
Una vez que uno se vuelve bueno, se vuelve mucho mas rapido
Equipos usando TDD reportan un incremento de un 2050 % develocidad y un 80 % de reduccion de defectos el primer ano
Jose Luis Diaz 26 de junio de 2014 39 / 80
Testing Test First Development
Empujar el desarrollo con Test
Escribir Tests antes de escribir la implementacion
Refactor, para mejorar la calidad
Mocks, stubs, y shunts
Inyeccion de dependencias
Jose Luis Diaz 26 de junio de 2014 40 / 80
Testing Test First Development
Empujar el desarrollo con Test
Escribir Tests antes de escribir la implementacion
Refactor, para mejorar la calidad
Mocks, stubs, y shunts
Inyeccion de dependencias
Jose Luis Diaz 26 de junio de 2014 40 / 80
Testing Test First Development
Empujar el desarrollo con Test
Escribir Tests antes de escribir la implementacion
Refactor, para mejorar la calidad
Mocks, stubs, y shunts
Inyeccion de dependencias
Jose Luis Diaz 26 de junio de 2014 40 / 80
Testing Test First Development
Empujar el desarrollo con Test
Escribir Tests antes de escribir la implementacion
Refactor, para mejorar la calidad
Mocks, stubs, y shunts
Inyeccion de dependencias
Jose Luis Diaz 26 de junio de 2014 40 / 80
Testing Test First Development
Beneficios de TDD
Enfocarse en buenos principios de diseno
Separacion de responsabilidades: hacerlo funcionar y asegurar calidad
Desarmar tareas complejas en tareas mas simples
Un conjunto completo de Tests de regresion
Jose Luis Diaz 26 de junio de 2014 41 / 80
Testing Test First Development
Beneficios de TDD
Enfocarse en buenos principios de diseno
Separacion de responsabilidades: hacerlo funcionar y asegurar calidad
Desarmar tareas complejas en tareas mas simples
Un conjunto completo de Tests de regresion
Jose Luis Diaz 26 de junio de 2014 41 / 80
Testing Test First Development
Beneficios de TDD
Enfocarse en buenos principios de diseno
Separacion de responsabilidades: hacerlo funcionar y asegurar calidad
Desarmar tareas complejas en tareas mas simples
Un conjunto completo de Tests de regresion
Jose Luis Diaz 26 de junio de 2014 41 / 80
Testing Test First Development
Beneficios de TDD
Enfocarse en buenos principios de diseno
Separacion de responsabilidades: hacerlo funcionar y asegurar calidad
Desarmar tareas complejas en tareas mas simples
Un conjunto completo de Tests de regresion
Jose Luis Diaz 26 de junio de 2014 41 / 80
Testing Test First Development
¿Por que funciona?
Nos mantiene enfocado en las tareas adecuadas en el momentoadecuado
Separa las tareas en pedazos manejables
Separa el desarrollo en la forma natural en la que pensamos
Jose Luis Diaz 26 de junio de 2014 42 / 80
Testing Test First Development
¿Por que funciona?
Nos mantiene enfocado en las tareas adecuadas en el momentoadecuado
Separa las tareas en pedazos manejables
Separa el desarrollo en la forma natural en la que pensamos
Jose Luis Diaz 26 de junio de 2014 42 / 80
Testing Test First Development
¿Por que funciona?
Nos mantiene enfocado en las tareas adecuadas en el momentoadecuado
Separa las tareas en pedazos manejables
Separa el desarrollo en la forma natural en la que pensamos
Jose Luis Diaz 26 de junio de 2014 42 / 80
Testing Test First Development
Herramientas para Test unitario
xUnit JUnit para java, NUnit para Net
herramientas de cobertura de codigo
frameworks para Mocking
Jose Luis Diaz 26 de junio de 2014 43 / 80
Testing Test First Development
Herramientas para Test unitario
xUnit JUnit para java, NUnit para Net
herramientas de cobertura de codigo
frameworks para Mocking
Jose Luis Diaz 26 de junio de 2014 43 / 80
Testing Test First Development
Herramientas para Test unitario
xUnit JUnit para java, NUnit para Net
herramientas de cobertura de codigo
frameworks para Mocking
Jose Luis Diaz 26 de junio de 2014 43 / 80
Testing Test First Development
Los tres primeros pasos para testear
Escribir un Test que falle
Hacerlo andar
Refactorizar por calidad
Jose Luis Diaz 26 de junio de 2014 44 / 80
Testing Test First Development
Los tres primeros pasos para testear
Escribir un Test que falle
Hacerlo andar
Refactorizar por calidad
Jose Luis Diaz 26 de junio de 2014 44 / 80
Testing Test First Development
Los tres primeros pasos para testear
Escribir un Test que falle
Hacerlo andar
Refactorizar por calidad
Jose Luis Diaz 26 de junio de 2014 44 / 80
Testing Test First Development
Rojo, Verde
Barra Roja: escribir un metodo que tenga una asercion en como sedeberıa llamar al metodo
Barra Verde: Hacerlo andar!
Refactorizar: Limpiarlo y hacerlo soportale
Repetir
Jose Luis Diaz 26 de junio de 2014 45 / 80
Testing Test First Development
Rojo, Verde
Barra Roja: escribir un metodo que tenga una asercion en como sedeberıa llamar al metodo
Barra Verde: Hacerlo andar!
Refactorizar: Limpiarlo y hacerlo soportale
Repetir
Jose Luis Diaz 26 de junio de 2014 45 / 80
Testing Test First Development
Rojo, Verde
Barra Roja: escribir un metodo que tenga una asercion en como sedeberıa llamar al metodo
Barra Verde: Hacerlo andar!
Refactorizar: Limpiarlo y hacerlo soportale
Repetir
Jose Luis Diaz 26 de junio de 2014 45 / 80
Testing Test First Development
Rojo, Verde
Barra Roja: escribir un metodo que tenga una asercion en como sedeberıa llamar al metodo
Barra Verde: Hacerlo andar!
Refactorizar: Limpiarlo y hacerlo soportale
Repetir
Jose Luis Diaz 26 de junio de 2014 45 / 80
Testing Test First Development
Escribir un Test que falle
TDD no es directamente obtener la barra verde, es convertir la barraroja en barra verde
Siempre hay que empezar con un test que falle
Si un test no falla estrepitosamente no es un test para nada
La verificacion de un test podrıa ser ver que un test fallo antes defuncionar
Jose Luis Diaz 26 de junio de 2014 46 / 80
Testing Test First Development
Escribir un Test que falle
TDD no es directamente obtener la barra verde, es convertir la barraroja en barra verde
Siempre hay que empezar con un test que falle
Si un test no falla estrepitosamente no es un test para nada
La verificacion de un test podrıa ser ver que un test fallo antes defuncionar
Jose Luis Diaz 26 de junio de 2014 46 / 80
Testing Test First Development
Escribir un Test que falle
TDD no es directamente obtener la barra verde, es convertir la barraroja en barra verde
Siempre hay que empezar con un test que falle
Si un test no falla estrepitosamente no es un test para nada
La verificacion de un test podrıa ser ver que un test fallo antes defuncionar
Jose Luis Diaz 26 de junio de 2014 46 / 80
Testing Test First Development
Escribir un Test que falle
TDD no es directamente obtener la barra verde, es convertir la barraroja en barra verde
Siempre hay que empezar con un test que falle
Si un test no falla estrepitosamente no es un test para nada
La verificacion de un test podrıa ser ver que un test fallo antes defuncionar
Jose Luis Diaz 26 de junio de 2014 46 / 80
Testing Test First Development
Celebrar la barra Roja
Los Tests que son mas valiosos son los que fallan.
Tenemos que hacer un monton para obtener la barra roja
Tenemos que pensar que hace el metodo que queremos testearDefinir como lo vamos a llamarDefinir que va a devolver
Jose Luis Diaz 26 de junio de 2014 47 / 80
Testing Test First Development
Celebrar la barra Roja
Los Tests que son mas valiosos son los que fallan.
Tenemos que hacer un monton para obtener la barra roja
Tenemos que pensar que hace el metodo que queremos testearDefinir como lo vamos a llamarDefinir que va a devolver
Jose Luis Diaz 26 de junio de 2014 47 / 80
Testing Test First Development
Celebrar la barra Roja
Los Tests que son mas valiosos son los que fallan.
Tenemos que hacer un monton para obtener la barra roja
Tenemos que pensar que hace el metodo que queremos testear
Definir como lo vamos a llamarDefinir que va a devolver
Jose Luis Diaz 26 de junio de 2014 47 / 80
Testing Test First Development
Celebrar la barra Roja
Los Tests que son mas valiosos son los que fallan.
Tenemos que hacer un monton para obtener la barra roja
Tenemos que pensar que hace el metodo que queremos testearDefinir como lo vamos a llamar
Definir que va a devolver
Jose Luis Diaz 26 de junio de 2014 47 / 80
Testing Test First Development
Celebrar la barra Roja
Los Tests que son mas valiosos son los que fallan.
Tenemos que hacer un monton para obtener la barra roja
Tenemos que pensar que hace el metodo que queremos testearDefinir como lo vamos a llamarDefinir que va a devolver
Jose Luis Diaz 26 de junio de 2014 47 / 80
Testing Test First Development
Obteniendo la barra verde
Obtener la barra roja esta bien, quedarse ahı no
Obtener la barra verde puede ser facil, quedarse ahı no
Pasos separados:
Hacerlo andarHacerlo mantenible
Jose Luis Diaz 26 de junio de 2014 48 / 80
Testing Test First Development
Obteniendo la barra verde
Obtener la barra roja esta bien, quedarse ahı no
Obtener la barra verde puede ser facil, quedarse ahı no
Pasos separados:
Hacerlo andarHacerlo mantenible
Jose Luis Diaz 26 de junio de 2014 48 / 80
Testing Test First Development
Obteniendo la barra verde
Obtener la barra roja esta bien, quedarse ahı no
Obtener la barra verde puede ser facil, quedarse ahı no
Pasos separados:
Hacerlo andarHacerlo mantenible
Jose Luis Diaz 26 de junio de 2014 48 / 80
Testing Test First Development
Obteniendo la barra verde
Obtener la barra roja esta bien, quedarse ahı no
Obtener la barra verde puede ser facil, quedarse ahı no
Pasos separados:
Hacerlo andar
Hacerlo mantenible
Jose Luis Diaz 26 de junio de 2014 48 / 80
Testing Test First Development
Obteniendo la barra verde
Obtener la barra roja esta bien, quedarse ahı no
Obtener la barra verde puede ser facil, quedarse ahı no
Pasos separados:
Hacerlo andarHacerlo mantenible
Jose Luis Diaz 26 de junio de 2014 48 / 80
Testing Test First Development
Refactorizar el Codigo
Limpiar la logica, hacerla facil de leer
Renombrar metodos, hacer que reflejen lo que hacen
Eliminar redundancia, encapsular variacion
Jose Luis Diaz 26 de junio de 2014 49 / 80
Testing Test First Development
Refactorizar el Codigo
Limpiar la logica, hacerla facil de leer
Renombrar metodos, hacer que reflejen lo que hacen
Eliminar redundancia, encapsular variacion
Jose Luis Diaz 26 de junio de 2014 49 / 80
Testing Test First Development
Refactorizar el Codigo
Limpiar la logica, hacerla facil de leer
Renombrar metodos, hacer que reflejen lo que hacen
Eliminar redundancia, encapsular variacion
Jose Luis Diaz 26 de junio de 2014 49 / 80
Testing Test First Development
Refactorizar los Tests
Cuando uno esta intentando entender que tiene que hacer,probablemente escriba muchos tests
Este tipo de triangulacion puede ser util
Los Tests extras, borrarlos!
Jose Luis Diaz 26 de junio de 2014 50 / 80
Testing Test First Development
Refactorizar los Tests
Cuando uno esta intentando entender que tiene que hacer,probablemente escriba muchos tests
Este tipo de triangulacion puede ser util
Los Tests extras, borrarlos!
Jose Luis Diaz 26 de junio de 2014 50 / 80
Testing Test First Development
Refactorizar los Tests
Cuando uno esta intentando entender que tiene que hacer,probablemente escriba muchos tests
Este tipo de triangulacion puede ser util
Los Tests extras, borrarlos!
Jose Luis Diaz 26 de junio de 2014 50 / 80
Testing Test First Development
Un ejemplo
Supongamos que quiero escribir una clase “adder”
Empezarıa escribiendo un test que falla
Y el codigo mas simple para que compile
Jose Luis Diaz 26 de junio de 2014 51 / 80
Testing Test First Development
Un ejemplo
Supongamos que quiero escribir una clase “adder”
Empezarıa escribiendo un test que falla
Y el codigo mas simple para que compile
Jose Luis Diaz 26 de junio de 2014 51 / 80
Testing Test First Development
Un ejemplo
Supongamos que quiero escribir una clase “adder”
Empezarıa escribiendo un test que falla1 Adder adder = new Adder();2 assertEquals(2, adder.add(1,1));
Y el codigo mas simple para que compile
Jose Luis Diaz 26 de junio de 2014 51 / 80
Testing Test First Development
Un ejemplo
Supongamos que quiero escribir una clase “adder”
Empezarıa escribiendo un test que falla1 Adder adder = new Adder();2 assertEquals(2, adder.add(1,1));
Y el codigo mas simple para que compile
Jose Luis Diaz 26 de junio de 2014 51 / 80
Testing Test First Development
Un ejemplo
Supongamos que quiero escribir una clase “adder”
Empezarıa escribiendo un test que falla1 Adder adder = new Adder();2 assertEquals(2, adder.add(1,1));
Y el codigo mas simple para que compile1 public class Adder {2 public int add(int p1, int p2) {3 return 0;4 }5 }
Jose Luis Diaz 26 de junio de 2014 51 / 80
Testing Test First Development
Jose Luis Diaz 26 de junio de 2014 52 / 80
Testing Test First Development
Una buena idea
Cual es la forma mas rapida de ir hacia la barra verde?
Jose Luis Diaz 26 de junio de 2014 53 / 80
Testing Test First Development
Una buena idea
Cual es la forma mas rapida de ir hacia la barra verde?1 public class Adder {2 public int add(int p1, int p2) {3 return 2;4 }5 }
Jose Luis Diaz 26 de junio de 2014 53 / 80
Testing Test First Development
Jose Luis Diaz 26 de junio de 2014 54 / 80
Testing Test First Development
Intentemos otro mas
1 assertEquals(4, adder.add(1,1));
Jose Luis Diaz 26 de junio de 2014 55 / 80
Testing Test First Development
Jose Luis Diaz 26 de junio de 2014 56 / 80
Testing Test First Development
Opciones
Podemos agregar logica condicional
o simplemente
Jose Luis Diaz 26 de junio de 2014 57 / 80
Testing Test First Development
Opciones
Podemos agregar logica condicional
o simplemente
Jose Luis Diaz 26 de junio de 2014 57 / 80
Testing Test First Development
Opciones
Podemos agregar logica condicional1 public class Adder {2 public int add(int p1, int p2) {3 if (p1 == 1 && p2 == 1) return 2;4 if (p1 == 2 && p2 == 2) return 4;5 return 06 }7 }
o simplemente
Jose Luis Diaz 26 de junio de 2014 57 / 80
Testing Test First Development
Opciones
Podemos agregar logica condicional1 public class Adder {2 public int add(int p1, int p2) {3 if (p1 == 1 && p2 == 1) return 2;4 if (p1 == 2 && p2 == 2) return 4;5 return 06 }7 }
o simplemente
Jose Luis Diaz 26 de junio de 2014 57 / 80
Testing Test First Development
Opciones
Podemos agregar logica condicional1 public class Adder {2 public int add(int p1, int p2) {3 if (p1 == 1 && p2 == 1) return 2;4 if (p1 == 2 && p2 == 2) return 4;5 return 06 }7 }
o simplemente1 public class Adder {2 public int add(int p1, int p2) {3 return p1+p24 }5 }
Jose Luis Diaz 26 de junio de 2014 57 / 80
Testing Test First Development
Jose Luis Diaz 26 de junio de 2014 58 / 80
Testing Test First Development
Caracterısticas de un buen test
Corren Rapido, deben tener un setup y un teardown cortos. Los testdeben correr aislados y no deberıa importar el orden en que corran.
Bien nombrados, si una abstraccion no tiene un nombre adecuadoprobablemente este mal
Usar datos que representan como el sistema realmente va a serutilizado
Jose Luis Diaz 26 de junio de 2014 59 / 80
Testing Test First Development
Caracterısticas de un buen test
Corren Rapido, deben tener un setup y un teardown cortos. Los testdeben correr aislados y no deberıa importar el orden en que corran.
Bien nombrados, si una abstraccion no tiene un nombre adecuadoprobablemente este mal
Usar datos que representan como el sistema realmente va a serutilizado
Jose Luis Diaz 26 de junio de 2014 59 / 80
Testing Test First Development
Caracterısticas de un buen test
Corren Rapido, deben tener un setup y un teardown cortos. Los testdeben correr aislados y no deberıa importar el orden en que corran.
Bien nombrados, si una abstraccion no tiene un nombre adecuadoprobablemente este mal
Usar datos que representan como el sistema realmente va a serutilizado
Jose Luis Diaz 26 de junio de 2014 59 / 80
Testing Test First Development
Algunos TIPS
Hacer que el Test primero falle
Hacer que los Tests corran rapido testeando solo lo que se necesitatestear
No hay que asumir que los test corren en ningun orden
Arrancar con el caso mas simple
Asegurarse que el Test mantiene valida una intencion
Mantener los Tests repetibles
No harcodear locaciones
Hacer los mensajes de error informativos
Jose Luis Diaz 26 de junio de 2014 60 / 80
Testing Test First Development
Algunos TIPS
Hacer que el Test primero falle
Hacer que los Tests corran rapido testeando solo lo que se necesitatestear
No hay que asumir que los test corren en ningun orden
Arrancar con el caso mas simple
Asegurarse que el Test mantiene valida una intencion
Mantener los Tests repetibles
No harcodear locaciones
Hacer los mensajes de error informativos
Jose Luis Diaz 26 de junio de 2014 60 / 80
Testing Test First Development
Algunos TIPS
Hacer que el Test primero falle
Hacer que los Tests corran rapido testeando solo lo que se necesitatestear
No hay que asumir que los test corren en ningun orden
Arrancar con el caso mas simple
Asegurarse que el Test mantiene valida una intencion
Mantener los Tests repetibles
No harcodear locaciones
Hacer los mensajes de error informativos
Jose Luis Diaz 26 de junio de 2014 60 / 80
Testing Test First Development
Algunos TIPS
Hacer que el Test primero falle
Hacer que los Tests corran rapido testeando solo lo que se necesitatestear
No hay que asumir que los test corren en ningun orden
Arrancar con el caso mas simple
Asegurarse que el Test mantiene valida una intencion
Mantener los Tests repetibles
No harcodear locaciones
Hacer los mensajes de error informativos
Jose Luis Diaz 26 de junio de 2014 60 / 80
Testing Test First Development
Algunos TIPS
Hacer que el Test primero falle
Hacer que los Tests corran rapido testeando solo lo que se necesitatestear
No hay que asumir que los test corren en ningun orden
Arrancar con el caso mas simple
Asegurarse que el Test mantiene valida una intencion
Mantener los Tests repetibles
No harcodear locaciones
Hacer los mensajes de error informativos
Jose Luis Diaz 26 de junio de 2014 60 / 80
Testing Test First Development
Algunos TIPS
Hacer que el Test primero falle
Hacer que los Tests corran rapido testeando solo lo que se necesitatestear
No hay que asumir que los test corren en ningun orden
Arrancar con el caso mas simple
Asegurarse que el Test mantiene valida una intencion
Mantener los Tests repetibles
No harcodear locaciones
Hacer los mensajes de error informativos
Jose Luis Diaz 26 de junio de 2014 60 / 80
Testing Test First Development
Algunos TIPS
Hacer que el Test primero falle
Hacer que los Tests corran rapido testeando solo lo que se necesitatestear
No hay que asumir que los test corren en ningun orden
Arrancar con el caso mas simple
Asegurarse que el Test mantiene valida una intencion
Mantener los Tests repetibles
No harcodear locaciones
Hacer los mensajes de error informativos
Jose Luis Diaz 26 de junio de 2014 60 / 80
Testing Test First Development
Algunos TIPS
Hacer que el Test primero falle
Hacer que los Tests corran rapido testeando solo lo que se necesitatestear
No hay que asumir que los test corren en ningun orden
Arrancar con el caso mas simple
Asegurarse que el Test mantiene valida una intencion
Mantener los Tests repetibles
No harcodear locaciones
Hacer los mensajes de error informativos
Jose Luis Diaz 26 de junio de 2014 60 / 80
Testing Test First Development
Que es difıcil testear
Metodos que retornan void
Metodos static, o private
Metodos que no son determiniticos
Metodos que no son cohesivos
Jerarquıa de clases profundas
Cuando se construyen objetos en los constructores
Estado global
Jose Luis Diaz 26 de junio de 2014 61 / 80
Testing Test First Development
Que es difıcil testear
Metodos que retornan void
Metodos static, o private
Metodos que no son determiniticos
Metodos que no son cohesivos
Jerarquıa de clases profundas
Cuando se construyen objetos en los constructores
Estado global
Jose Luis Diaz 26 de junio de 2014 61 / 80
Testing Test First Development
Que es difıcil testear
Metodos que retornan void
Metodos static, o private
Metodos que no son determiniticos
Metodos que no son cohesivos
Jerarquıa de clases profundas
Cuando se construyen objetos en los constructores
Estado global
Jose Luis Diaz 26 de junio de 2014 61 / 80
Testing Test First Development
Que es difıcil testear
Metodos que retornan void
Metodos static, o private
Metodos que no son determiniticos
Metodos que no son cohesivos
Jerarquıa de clases profundas
Cuando se construyen objetos en los constructores
Estado global
Jose Luis Diaz 26 de junio de 2014 61 / 80
Testing Test First Development
Que es difıcil testear
Metodos que retornan void
Metodos static, o private
Metodos que no son determiniticos
Metodos que no son cohesivos
Jerarquıa de clases profundas
Cuando se construyen objetos en los constructores
Estado global
Jose Luis Diaz 26 de junio de 2014 61 / 80
Testing Test First Development
Que es difıcil testear
Metodos que retornan void
Metodos static, o private
Metodos que no son determiniticos
Metodos que no son cohesivos
Jerarquıa de clases profundas
Cuando se construyen objetos en los constructores
Estado global
Jose Luis Diaz 26 de junio de 2014 61 / 80
Testing Test First Development
Que es difıcil testear
Metodos que retornan void
Metodos static, o private
Metodos que no son determiniticos
Metodos que no son cohesivos
Jerarquıa de clases profundas
Cuando se construyen objetos en los constructores
Estado global
Jose Luis Diaz 26 de junio de 2014 61 / 80
Testing Test First Development
Preguntas para hacerse
Cuanto difiere TDD de lo que yo originalmente pensaba
Que beneficio puedo obtener de TDD
Como decidir cual es el numero correcto de Unit Test por clase
Jose Luis Diaz 26 de junio de 2014 62 / 80
Testing Test First Development
Preguntas para hacerse
Cuanto difiere TDD de lo que yo originalmente pensaba
Que beneficio puedo obtener de TDD
Como decidir cual es el numero correcto de Unit Test por clase
Jose Luis Diaz 26 de junio de 2014 62 / 80
Testing Test First Development
Preguntas para hacerse
Cuanto difiere TDD de lo que yo originalmente pensaba
Que beneficio puedo obtener de TDD
Como decidir cual es el numero correcto de Unit Test por clase
Jose Luis Diaz 26 de junio de 2014 62 / 80
Testing Tecnicas de testing
Agenda
1 Principios de disenoOcultacion de la informacionHacia los objetos
2 SOLIDSingle responsibility principleOpen-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle
3 TestingTest First DevelopmentTecnicas de testingDependencias
Jose Luis Diaz 26 de junio de 2014 63 / 80
Testing Tecnicas de testing
Fases de un test
Setup
Ejercitarlo
Verificarlo
Teardown
Jose Luis Diaz 26 de junio de 2014 64 / 80
Testing Tecnicas de testing
Fases de un test
Setup
Ejercitarlo
Verificarlo
Teardown
Jose Luis Diaz 26 de junio de 2014 64 / 80
Testing Tecnicas de testing
Fases de un test
Setup
Ejercitarlo
Verificarlo
Teardown
Jose Luis Diaz 26 de junio de 2014 64 / 80
Testing Tecnicas de testing
Fases de un test
Setup
Ejercitarlo
Verificarlo
Teardown
Jose Luis Diaz 26 de junio de 2014 64 / 80
Testing Tecnicas de testing
Dos tipos de test
Boundary tests: definir condiciones de frontera
Workflow tests: testear una secuencia de eventos
Jose Luis Diaz 26 de junio de 2014 65 / 80
Testing Tecnicas de testing
Dos tipos de test
Boundary tests: definir condiciones de frontera
Workflow tests: testear una secuencia de eventos
Jose Luis Diaz 26 de junio de 2014 65 / 80
Testing Tecnicas de testing
Dos tipos de test
Boundary tests: definir condiciones de frontera
Workflow tests: testear una secuencia de eventos
Jose Luis Diaz 26 de junio de 2014 65 / 80
Testing Tecnicas de testing
Boundary tests
Los tests de fronteras estan expresado por aserciones
Usan algun framework de unit testing
Se aseguran que se retornen valores correctos para determinadosparametros
Jose Luis Diaz 26 de junio de 2014 66 / 80
Testing Tecnicas de testing
Boundary tests
Los tests de fronteras estan expresado por aserciones
Usan algun framework de unit testing
Se aseguran que se retornen valores correctos para determinadosparametros
Jose Luis Diaz 26 de junio de 2014 66 / 80
Testing Tecnicas de testing
Boundary tests
Los tests de fronteras estan expresado por aserciones
Usan algun framework de unit testing
Se aseguran que se retornen valores correctos para determinadosparametros
Jose Luis Diaz 26 de junio de 2014 66 / 80
Testing Tecnicas de testing
Boundary tests
Los tests de fronteras estan expresado por aserciones
Usan algun framework de unit testing
Se aseguran que se retornen valores correctos para determinadosparametros
Jose Luis Diaz 26 de junio de 2014 66 / 80
Testing Tecnicas de testing
Workflow Testing
Los test de secuencia usan objetos de tipo Mock para inspeccionar yverificar las llamadas hechas en una secuencia especifica
Usan un framework de mocking
Aseguran que el flujo funciona correctamente
Jose Luis Diaz 26 de junio de 2014 67 / 80
Testing Tecnicas de testing
Workflow Testing
Los test de secuencia usan objetos de tipo Mock para inspeccionar yverificar las llamadas hechas en una secuencia especifica
Usan un framework de mocking
Aseguran que el flujo funciona correctamente
Jose Luis Diaz 26 de junio de 2014 67 / 80
Testing Tecnicas de testing
Workflow Testing
Los test de secuencia usan objetos de tipo Mock para inspeccionar yverificar las llamadas hechas en una secuencia especifica
Usan un framework de mocking
Aseguran que el flujo funciona correctamente
Jose Luis Diaz 26 de junio de 2014 67 / 80
Testing Tecnicas de testing
Workflow Testing
Los test de secuencia usan objetos de tipo Mock para inspeccionar yverificar las llamadas hechas en una secuencia especifica
Usan un framework de mocking
Aseguran que el flujo funciona correctamente
Jose Luis Diaz 26 de junio de 2014 67 / 80
Testing Tecnicas de testing
Manejando las dependencias
No todo lo que testeamos esta bajo nuestro control
Necesitamos poder manejar esas dependencias
Como hacemos para testear un webservice?
Jose Luis Diaz 26 de junio de 2014 68 / 80
Testing Tecnicas de testing
Manejando las dependencias
No todo lo que testeamos esta bajo nuestro control
Necesitamos poder manejar esas dependencias
Como hacemos para testear un webservice?
Jose Luis Diaz 26 de junio de 2014 68 / 80
Testing Tecnicas de testing
Manejando las dependencias
No todo lo que testeamos esta bajo nuestro control
Necesitamos poder manejar esas dependencias
Como hacemos para testear un webservice?
Jose Luis Diaz 26 de junio de 2014 68 / 80
Testing Tecnicas de testing
Manejando las dependencias
No todo lo que testeamos esta bajo nuestro control
Necesitamos poder manejar esas dependencias
Como hacemos para testear un webservice?
Jose Luis Diaz 26 de junio de 2014 68 / 80
Testing Tecnicas de testing
Mocks hechos a mano
Usualmente es una subclase de la clase que estamos mock-eando oimplementa la misma interface
Contienen metodos para agregar y remover estado
Escritos a mano; no hay necesidad de ningun framework
Jose Luis Diaz 26 de junio de 2014 69 / 80
Testing Tecnicas de testing
Mocks hechos a mano
Usualmente es una subclase de la clase que estamos mock-eando oimplementa la misma interface
Contienen metodos para agregar y remover estado
Escritos a mano; no hay necesidad de ningun framework
Jose Luis Diaz 26 de junio de 2014 69 / 80
Testing Tecnicas de testing
Mocks hechos a mano
Usualmente es una subclase de la clase que estamos mock-eando oimplementa la misma interface
Contienen metodos para agregar y remover estado
Escritos a mano; no hay necesidad de ningun framework
Jose Luis Diaz 26 de junio de 2014 69 / 80
Testing Tecnicas de testing
Mocks estaticos
Derivado de una clase, una interfase o un objeto
Usualmente es generador por una herramienta de mocking
Es inspeccionable o se puede grabar
Jose Luis Diaz 26 de junio de 2014 70 / 80
Testing Tecnicas de testing
Mocks estaticos
Derivado de una clase, una interfase o un objeto
Usualmente es generador por una herramienta de mocking
Es inspeccionable o se puede grabar
Jose Luis Diaz 26 de junio de 2014 70 / 80
Testing Tecnicas de testing
Mocks estaticos
Derivado de una clase, una interfase o un objeto
Usualmente es generador por una herramienta de mocking
Es inspeccionable o se puede grabar
Jose Luis Diaz 26 de junio de 2014 70 / 80
Testing Tecnicas de testing
Mocks inspeccionables
Estos mocks pueden estar condicionados diciendo que deben esperar
Una vez que el mock esta creado, el codigo puede ser testeado
Despues se verifica que las llamadas hayan sido correctas
Jose Luis Diaz 26 de junio de 2014 71 / 80
Testing Dependencias
Agenda
1 Principios de disenoOcultacion de la informacionHacia los objetos
2 SOLIDSingle responsibility principleOpen-closed principleLiskov substitution principleInterface segregation principleDependency inversion principle
3 TestingTest First DevelopmentTecnicas de testingDependencias
Jose Luis Diaz 26 de junio de 2014 72 / 80
Testing Dependencias
En vez de hacer esto
1 public class MyClass {2 public MyClass() throws IOException {3 this.thread = new Thread();4 this.fileWriter = new FileWriter(new File(‘‘myfile.txt’’));5 }6 }
Jose Luis Diaz 26 de junio de 2014 73 / 80
Testing Dependencias
Hacer esto
Delegar la creacion a una Factory1 public class MyClassFactory {2 public MyClass getWithDependencies() {3 Thread thread = new Thread();4 FileWriter fileWriter = new FileWriter(new File(‘‘myfile.txt’’));5 return new MyClass(thread, fileWriter)6 }7 }8
9 public class MyClass {10 public MyClass(Thread thread, FileWriter fileWriter) throws IOException {11 this.thread = thread;12 this.fileWriter = fileWriter;13 }14 }
Jose Luis Diaz 26 de junio de 2014 74 / 80
Testing Dependencias
Inyeccion de dependencias
En esta tecnica pasamos la dependencia en el constructor
Esto nos habilita a pasar tipos cuando lo creamos conveniente
Jose Luis Diaz 26 de junio de 2014 75 / 80
Testing Dependencias
Otro ejemplo
1 public class Motorboat {2 private Motor myMotor;3
4 public Motorboat() {5 myMotor = new V6_Cat_motor(); // oculta6 }7
8 }
Jose Luis Diaz 26 de junio de 2014 76 / 80
Testing Dependencias
Una opcion
1
2 public Motorboat(Motor aMotor) {3 myMotor = motor;4 }5
6 public Motorboat() {7 myMotor = new V6_Cat_motor();8 }
Jose Luis Diaz 26 de junio de 2014 77 / 80
Testing Dependencias
Otra opcion
1 public Motorboat() {2 myMotor = makeMotor();3 }4
5 protected static Motor makeMotor() {6 return new V6_Cat_motor()7 }
Jose Luis Diaz 26 de junio de 2014 78 / 80
Testing Dependencias
y una innerclass
1 public class MotorBoardTest {2 private Motorboat testMotorboat;3 static private Motor mockMotor = new MockMotor();4
5 @Before6 public void startupTest() {7 testMotorboat = new TesteableMotorboat();8 }9
10 private class TesteableMotorboat extends Motorboat {11 protected static Motor makeMotor() {12 return mockMotor;13 }14 }15 }
Jose Luis Diaz 26 de junio de 2014 79 / 80
Testing Dependencias
Gracias!
Jose Luis Diaz 26 de junio de 2014 80 / 80
top related