Más allá de TDD -...

Más allá de TDD

Carlos Fontela

[email protected]

No se puede mostrar la imagen. Puede que su equipo no tenga suficiente memoria para abrir la imagen o que ésta esté dañada. Reinicie el equipo y, a continuación, abra el archivo de nuevo. Si sigue apareciendo la x roja, puede que tenga que borrar la imagen e insertarla de nuevo.

Más allá de TDD

A3F

Carlos Fontela

[email protected]

Motivación y contexto

TDD tiene más de 10 años, pero…Desarrolladores no quieren “hacer testing”Testers desconfían de las pruebas escritas por

desarrolladoresLas pruebas antes del código se ven como antiLas pruebas antes del código se ven como anti

naturales¿Por qué?

Mal uso de los términos: “test”Y algunas cosas más…


Motivación y contexto

TDD tiene más de 10 años, pero…Desarrolladores no quieren “hacer testing”Testers desconfían de las pruebas escritas por

Las pruebas antes del código se ven como anti-

A3F

Las pruebas antes del código se ven como anti-

Mal uso de los términos: “test”

2

Objetivos

Entender la proliferación de “xDD”:

Test-Driven Development (TDD) y sus limitaciones

Acceptance Tests-Driven Development (ATDD)

Behaviour-Driven Development (BDD)

Domain-Driven Design (DDD)

3

Domain-Driven Design (DDD)

Especificación por ejemplos (SBE) o StoryDevelopment (STDD)

Y afines:

Automatización de pruebas de comportamiento

Automatización de pruebas de interacción

Sólo introductorio


Objetivos

Entender la proliferación de “xDD”:

Driven Development (TDD) y sus limitaciones

Driven Development (ATDD)

Driven Development (BDD)

A3F

Especificación por ejemplos (SBE) o Story-Test Driven

Automatización de pruebas de comportamiento

Automatización de pruebas de interacción

Temario

TDD: volver a las fuentes

TDD: limitaciones

BDD y ATDD al rescate

4

BDD y ATDD al rescate

Especificación por ejemplos

Herramientas


Temario

TDD: volver a las fuentes

A3F

Especificación por ejemplos

TDD: los inicios

TDD = Automatización +Test-First +Refactoring

Presentada por Kent Beck y Ward

5

Presentada por Kent Beck y Ward Cunningham


TDD: los inicios


A3F


TDD: ventajas (1)

Independencia del factor humanoCon su carga de subjetividad

Menor costo de repetición de las pruebasBueno para probar regresiones

Menor condicionamiento del autor por su

6

Menor condicionamiento del autor por su implementaciónY más pruebas negativas

Sin restricciones de implementación detalladaMás aún por escribirlas antes


TDD: ventajas (1)

Independencia del factor humanoCon su carga de subjetividad

Menor costo de repetición de las pruebasBueno para probar regresiones


A3F


Sin restricciones de implementación detalladaMás aún por escribirlas antes

TDD: ventajas (2)

Facilidad para mejoras de diseñoCon mucho menor riesgo y estrés

Pruebas sirven como documentación del uso esperado de clases y métodos

7

Mayor comprensión del diseño antes de codificarloUna especie de especificación de diseño

Sólo escribimos código para lo realmente necesarioLo que tiene pruebas


TDD: ventajas (2)

Facilidad para mejoras de diseñoCon mucho menor riesgo y estrés

Pruebas sirven como documentación del uso esperado de clases y métodos

A3F

Mayor comprensión del diseño antes de

Una especie de especificación de diseño

Sólo escribimos código para lo realmente

TDD: procedimiento

8


TDD: procedimiento

A3F

Problemas de TDD (1)

Se aplica sobre pruebas unitariasPrueban pequeñas porciones de códigoCentradas en clases y sus métodosNo hay visión de conjunto¿Efecto provocado por los nombres de las

9

¿Efecto provocado por los nombres de las herramientas? (xUnit…)

Antipatrón: clase de prueba por clase de aplicación + método de prueba por método de clase



Se aplica sobre pruebas unitariasPrueban pequeñas porciones de códigoCentradas en clases y sus métodos

¿Efecto provocado por los nombres de las

A3F

¿Efecto provocado por los nombres de las

Antipatrón: clase de prueba por clase de aplicación + método de prueba por método de


Hace foco en la palabra “test”¡Está en el nombre!

También en las herramientas (testXXX, @Test, …)

Dan North empezó a sugerir usar “should” o “must” en BDD

10

“must” en BDD

Mucho énfasis en herramientas para programadoresPero no en otros perfiles

Incluso el vocabulario de la metodología es muy técnico



Hace foco en la palabra “test”

También en las herramientas (testXXX, @Test, …)

Dan North empezó a sugerir usar “should” o

A3F

Mucho énfasis en herramientas para

Incluso el vocabulario de la metodología es muy

ATDD / BDD: fundamentos

Lo que importa es generar valor para el negocio

Y era uno de los principios básicos de XP

TDD, como se terminó implementando, no cubre los “customer tests” de Kent Beck

11

Las palabras importan

El vocabulario de negocio es importante

Y debe ser consistente

“Lenguaje ubicuo” de Eric Evans


ATDD / BDD: fundamentos

Lo que importa es generar valor para el negocio

Y era uno de los principios básicos de XP

TDD, como se terminó implementando, no cubre los “customer tests” de Kent Beck

A3F

El vocabulario de negocio es importante

ATDD / BDD: diferencias

ATDDTest-First con pruebas de aceptaciónAutomatizadas o noRequerimiento (US) => Pruebas de aceptación (UAT)Idea de especificación basada en ejemplosSi se automatiza: especificación ejecutable

12

Si se automatiza: especificación ejecutable

BDDTest-First con pruebas de comportamientoAutomatizadas al estilo de TDDUS con lenguaje del negocio => UAT con lenguaje de

comportamientoIdea de especificación basada en comportamiento


ATDD / BDD: diferencias

First con pruebas de aceptación

Requerimiento (US) => Pruebas de aceptación (UAT)Idea de especificación basada en ejemplosSi se automatiza: especificación ejecutable

A3F

Si se automatiza: especificación ejecutable

First con pruebas de comportamientoAutomatizadas al estilo de TDDUS con lenguaje del negocio => UAT con lenguaje de

Idea de especificación basada en comportamiento

ATDD: particularidades

Premisa: al cliente le importa la funcionalidad y sus beneficios, no la implementación

Condiciones de las pruebas de aceptación:Que el cliente las considere propias

13

Que sean escritas en conjunto por el cliente, el tester y el desarrollador

Que se basen en el qué y no en el cómo

Que estén expresadas en el lenguaje del dominio del problema

La automatización no es lo más importante


ATDD: particularidades

Premisa: al cliente le importa la funcionalidad y sus beneficios, no la implementación

Condiciones de las pruebas de aceptación:Que el cliente las considere propias

A3F

Que sean escritas en conjunto por el cliente, el

Que se basen en el qué y no en el cómo

Que estén expresadas en el lenguaje del dominio

La automatización no es lo más importante

BDD: particularidades

Premisa: no pensar en términos de pruebas de código, sino de comportamiento de la aplicaciónMuy basado en DDD

US => escenarios

14

US => escenariosGiven… When… Then…

Los escenarios son pruebas

Una clase de prueba por US

Se planteó automatizada desde los iniciosTDD bien realizado


BDD: particularidades

Premisa: no pensar en términos de pruebas de código, sino de comportamiento de la

A3F

Los escenarios son pruebas

Una clase de prueba por US

Se planteó automatizada desde los inicios

ATDD/BDD: coincidencias de objetivos

Mejorar especificacionesFacilitar el paso de especificaciones a testsMejorar comunicación entre stakeholders,

analistas, desarrolladores y testersMejorar visibilidad de satisfacción de requisitos

15

Mejorar visibilidad de satisfacción de requisitos y del avance

Disminuir gold-platingLenguaje único, más cerca del consumidor


ATDD/BDD: coincidencias de objetivos

Facilitar el paso de especificaciones a testsMejorar comunicación entre stakeholders,

analistas, desarrolladores y testersMejorar visibilidad de satisfacción de requisitos

A3F

Mejorar visibilidad de satisfacción de requisitos

Lenguaje único, más cerca del consumidor

ATDD automatizado: procedimiento

16


ATDD automatizado: procedimiento

A3F

BDD: procedimiento

17


BDD: procedimiento

A3F

BDD, TDD y más allá

VocabularioATDD más cercano a analistas de negocioBDD más cercano al diseño OO

Las diferencias, hoy, son mínimasPara nosotros: BDD = ATDD

18

Para nosotros: BDD = ATDDNo se prueba interfaz de usuario ni

interaccionesHay algunos trabajos en curso

Dentro de la comunidad de Selenium sobre todo


BDD, TDD y más allá

ATDD más cercano a analistas de negocioBDD más cercano al diseño OO

Las diferencias, hoy, son mínimasPara nosotros: BDD = ATDD

A3F

Para nosotros: BDD = ATDDNo se prueba interfaz de usuario ni

Hay algunos trabajos en cursoDentro de la comunidad de Selenium sobre todo

ATDD / BDD como especificación

Son especificaciones mediante ejemplosPor extensión y no por “intensión”

Los escenarios son ejemplos de requerimientos, que se pueden convertir fácilmente en pruebas automatizadas

19

automatizadas

Las que Beck llamaba “customer tests”

No olvidar que a veces es necesario especificar en forma abstracta

US en 1 o 2 oraciones debe acompañar a los escenarios de UAT


ATDD / BDD como especificación

Son especificaciones mediante ejemplosPor extensión y no por “intensión”

Los escenarios son ejemplos de requerimientos, que se pueden convertir fácilmente en pruebas

A3F

Las que Beck llamaba “customer tests”

No olvidar que a veces es necesario especificar en forma abstracta

US en 1 o 2 oraciones debe acompañar a los

Enfoque tradicional

3 o más actividades distintasEspecificación de requerimientos

Diseño y construcción

Verificación y validación

20

3 o más perfiles diferentesCliente, analista funcional o de negocio

Desarrollador

Tester

Problemas de comunicaciónTeléfono descompuesto


Enfoque tradicional

3 o más actividades distintasEspecificación de requerimientos

A3F

3 o más perfiles diferentesCliente, analista funcional o de negocio

Problemas de comunicación

Especificar con ejemplos

Especificación podría incluir ejemplos / escenarios

Explicar cómo hacer un nudo de corbata

Los ejemplos sirven como casos de prueba

Para testers

Para desarrolladores

21

Para desarrolladores

Todos trabajan sobre lo mismo

Se evita el teléfono descompuesto

Los escenarios se construyen una sola vez

=> Specification By Example (SBE) o StoryDriven Development (STDD)


Especificar con ejemplos

Especificación podría incluir ejemplos / escenarios

Explicar cómo hacer un nudo de corbata

Los ejemplos sirven como casos de prueba

A3F

Todos trabajan sobre lo mismo

Se evita el teléfono descompuesto

Los escenarios se construyen una sola vez

=> Specification By Example (SBE) o Story-Test Driven Development (STDD)

Roles: analista

Enfoque tradicional“Traductor” entre:

ClientesDesarrolladores y testers

Escucha expectativas, deseos y necesidadesElabora especificaciones y requisitos

22

Elabora especificaciones y requisitosY los prioriza

Tiende a ver el camino feliz

SBEDebe ser un facilitador de intercambio de conocimiento


Roles: analista

Escucha expectativas, deseos y necesidadesElabora especificaciones y requisitos

A3F

Elabora especificaciones y requisitos

Debe ser un facilitador de intercambio de conocimiento

Roles: tester

Enfoque tradicionalValidador del producto contra las especificacionesRecibe especificacionesElabora casos de prueba en base a escenariosEjecuta casos de prueba

23

Especialista en “romper” la aplicaciónNo habla con el cliente: el analista es su “proxy”

SBEParticipa con todos en la elaboración de los escenarios y

ejemplos


Roles: tester

Validador del producto contra las especificaciones

Elabora casos de prueba en base a escenarios

A3F

Especialista en “romper” la aplicaciónNo habla con el cliente: el analista es su “proxy”

Participa con todos en la elaboración de los escenarios y

Roles: desarrollador

Enfoque tradicionalDiseñador y constructor del productoRecibe especificacionesElabora un diseño y lo plasma en códigoEjecuta pruebas unitarias y de integración ad

24

Especialista en analizar casos límiteNo habla con el cliente: el analista es su “proxy”

SBEParticipa con todos en la elaboración de los escenarios y

ejemplos


Roles: desarrollador

Diseñador y constructor del producto

Elabora un diseño y lo plasma en códigoEjecuta pruebas unitarias y de integración ad-hoc

A3F

Especialista en analizar casos límiteNo habla con el cliente: el analista es su “proxy”

Participa con todos en la elaboración de los escenarios y

Roles: cliente o usuario

Enfoque tradicional

Sólo habla con un “proxy”: analista

SBEEs el primer autor de UATs

25

Pero hay que asistirloIncluso complementar su trabajo

Probablemente no se le ocurra pensar en probar fechas inválidas o precios negativos

Ojo: distinguir “usuario” y “cliente”Generalmente, el primero está más involucrado


Roles: cliente o usuario

Sólo habla con un “proxy”: analista

A3F

Probablemente no se le ocurra pensar en probar fechas inválidas o

Ojo: distinguir “usuario” y “cliente”Generalmente, el primero está más involucrado

Roles y SBE: workshops

1 workshop por iteración

Se establece un lenguaje común

El lenguaje ubicuo de Eric Evans en DDD

No hay un lenguaje de negocio y otro técnico

Este lenguaje pasa a los nombres en el código

26


Las habilidades se potencian

Surgen más requerimientos implícitos

Incluso casos no contemplados por nadie

Se aclaran gaps de análisis antes de trabajar

Hay revisión implícita

Más atendidos que documentos de requerimientos


Roles y SBE: workshops

Se establece un lenguaje común

El lenguaje ubicuo de Eric Evans en DDD

No hay un lenguaje de negocio y otro técnico


A3F


Surgen más requerimientos implícitos

Incluso casos no contemplados por nadie

Se aclaran gaps de análisis antes de trabajar

Más atendidos que documentos de requerimientos

Calidad y Testing

“Tratar de mejorar la calidad del software aumentando la cantidad de pruebas, es como tratar de adelgazar pesándose más seguido.”

Steve Mc Connell (Code Complete)

27

El testing es una técnica reactiva

Refrán: “Más vale prevenir que curar”

El costo es menor cuanto antes se enfrente el potencial problema

Queremos menores costos de testing y estabilización

Hacer las cosas una sola vez

Disminuir retrabajo


Calidad y Testing

“Tratar de mejorar la calidad del software aumentando la cantidad de pruebas, es como tratar de adelgazar pesándose más seguido.”

Steve Mc Connell (Code Complete)

A3F

El testing es una técnica reactiva

Refrán: “Más vale prevenir que curar”

El costo es menor cuanto antes se enfrente el potencial

Queremos menores costos de testing y estabilización

Hacer las cosas una sola vez

Calidad y desarrollo

La calidad no es algo que se haga al final

Métodos ágiles => Calidad continua(charla CF en Ágiles 2008)

Hay que hacer control de calidad sobre software de calidadSi sé con qué pruebas van a probar lo que hago, las corro antes

28

Si sé con qué pruebas van a probar lo que hago, las corro antesComo controles de velocidad en rutas

=> Menor retrabajo

Pruebas unitarias y técnicas de integración garantizan sólo calidad de diseño técnico


Calidad y desarrollo

La calidad no es algo que se haga al final

Métodos ágiles => Calidad continua

Hay que hacer control de calidad sobre software de

Si sé con qué pruebas van a probar lo que hago, las corro antes

A3F

Si sé con qué pruebas van a probar lo que hago, las corro antesComo controles de velocidad en rutas

Pruebas unitarias y técnicas de integración garantizan sólo calidad de diseño técnico

SBE / ATDD / BDD

Foco en comunicación, no en testing

TDD facilita el buen diseño

ATDD facilita construir el sistema correcto

Refactoring realmente simple

29

Con TDD, a veces había que cambiar pruebas

Y alguna incertidumbre podía quedar


SBE / ATDD / BDD

Foco en comunicación, no en testing

ATDD facilita construir el sistema correcto

Refactoring realmente simple

A3F

Con TDD, a veces había que cambiar pruebas

Y alguna incertidumbre podía quedar

SBE / ATDD / BDD e interfaces de usuario

IU depende de la interacción, no del comportamiento

Ya volveremos sobre esto

Generar una capa de servicios

Tests de IU son lentos

Testear la IU sabiendo que el comportamiento está bien

30

Testear la IU sabiendo que el comportamiento está bien es más tranquilizante

Y vamos a encontrar menos bugs

Ojo que algunos clientes sólo le creen a la IU

Y siempre hay que probar IU

Que cada cosa esté en su lugar, que funcionen los botones

Siempre después de un cambio en la IU


SBE / ATDD / BDD e interfaces de usuario

IU depende de la interacción, no del comportamiento


A3F


Y vamos a encontrar menos bugs

Ojo que algunos clientes sólo le creen a la IU

Que cada cosa esté en su lugar, que funcionen los botones

Siempre después de un cambio en la IU

Formatos de SBE (1)

TablasBuenas para representar entradas y salidas

calculablesMalas para representar flujos de tareasRequiere traductor a pruebas automáticas

31

Requiere traductor a pruebas automáticasTexto libre

Todos lo entiendenPobreza comunicativaRequiere traductor a pruebas automáticas


Formatos de SBE (1)

Buenas para representar entradas y salidas

Malas para representar flujos de tareasRequiere traductor a pruebas automáticas

A3F

Requiere traductor a pruebas automáticas

Requiere traductor a pruebas automáticas

Formatos de SBE (2)

DiagramasMuy expresivos para flujos de tareasFáciles de dibujar a mano alzadaDifíciles de manipular con herramientasDifíciles de derivar pruebas automáticas

32

Difíciles de derivar pruebas automáticasCódigo

Resistencia de roles no técnicosNo es buena herramienta de comunicaciónNo necesita traducción a código de pruebas


Formatos de SBE (2)

Muy expresivos para flujos de tareasFáciles de dibujar a mano alzadaDifíciles de manipular con herramientasDifíciles de derivar pruebas automáticas

A3F

Difíciles de derivar pruebas automáticas

Resistencia de roles no técnicosNo es buena herramienta de comunicaciónNo necesita traducción a código de pruebas

SBE: cuidados

Nadie debería desarrollar funcionalidades que no tengan su UAT

Si hay un bug en un test manual, habría que analizar:¿Faltaba un UAT?

33

¿Faltaba un UAT?¿Es realmente un bug?

Agregar UAT antes de funcionalidad que no lo tengaPero no en forma inconsulta


SBE: cuidados

Nadie debería desarrollar funcionalidades que

Si hay un bug en un test manual, habría que

A3F

Agregar UAT antes de funcionalidad que no lo

Pero no en forma inconsulta

Diseño de UAT

Cada test debería referirse a una sola regla de negocio simple

Describir el qué, no el cómoEs una especificación

34

Los casos de prueba no deben incluir detalles irrelevantes para la especificación, como un parámetro que no influye en el resultadoSacar lo superfluo o generarlo automáticamente

Cuando los valores de un parámetro son muy repetitivos, tratar de eliminar el parámetro


Diseño de UAT

Cada test debería referirse a una sola regla de

Describir el qué, no el cómo

A3F

Los casos de prueba no deben incluir detalles irrelevantes para la especificación, como un parámetro que no influye en el resultadoSacar lo superfluo o generarlo automáticamente

Cuando los valores de un parámetro son muy repetitivos, tratar de eliminar el parámetro

Limitaciones

A veces no hay ejemplos

i.e. si necesito generar números al azar

es una limitación del modelo

Situaciones en que la interacción importa más que el comportamiento

35

A veces se pierde la visión global del proyecto, al enfocarse tanto en ejemplos

Hacer “epics”, con UATs globales, si se puede

Pruebas difíciles de expresar o de ejecutar

Usabilidad

Performance

Stress


Limitaciones

i.e. si necesito generar números al azar

Situaciones en que la interacción importa más que el

A3F

A veces se pierde la visión global del proyecto, al

Hacer “epics”, con UATs globales, si se puede

Pruebas difíciles de expresar o de ejecutar

Todos los nombres

Agile Acceptance Testing

Acceptance Test-Driven Development

Behaviour-Driven Development

Specification By Example

Story-Test Driven Development

36

Story-Test Driven Development

Executable Specifications

Customer Tests

Functional Tests-Driven Development

Business-facing TDD

Black box requirements

Test driven requirements


Todos los nombres

Driven Development

A3F

Driven Development

Herramientas (1)

Cada una maneja distintos formatos y hace foco en distintos tipos de requerimientosHay que elegirla bien para mejorar la

comunicaciónNo hay por qué usar una sola

Pero tampoco podemos usar 10

37


Tests de dominio y comportamientoFit, FitNesse => tablasJbehave, RSpec, Concordion => comportamiento


Herramientas (1)

Cada una maneja distintos formatos y hace foco en distintos tipos de requerimientosHay que elegirla bien para mejorar la

No hay por qué usar una solaPero tampoco podemos usar 10

A3F


Tests de dominio y comportamiento

Jbehave, RSpec, Concordion => comportamiento

Herramientas (2)

Workflows y regresiónTextTest

Tests de interacciónSelenium, el más popular

38

Selenium, el más popular

CubicTest, herramienta para tests de Selenium en forma gráfica

StoryTestIQ, wiki para tests de Selenium

WebTest, vincula Fit y Selenium

JBehave y otros con patrón Page Object


Herramientas (2)

A3F

CubicTest, herramienta para tests de Selenium en

StoryTestIQ, wiki para tests de Selenium

WebTest, vincula Fit y Selenium

JBehave y otros con patrón Page Object

FIT

Trabaja con tablas

Tests fáciles de escribir y revisar

Colores rojo, amarillo y verde

No es bueno para flujos de tareas, sí para

39

No es bueno para flujos de tareas, sí para reglas calculablesFlujos con FitLibrary, pero complica una

herramienta sencilla

Se vinculan al código de pruebas mediante “fixtures”API para integrar código y tablas


Tests fáciles de escribir y revisar

Colores rojo, amarillo y verde


A3F


Flujos con FitLibrary, pero complica una

Se vinculan al código de pruebas mediante

API para integrar código y tablas

FitNesse

Formato tipo WikiPuede vincularse con FIT

lo más habitualSirve para código Java, Python, C++, .NET y

Smalltalk

40

SmalltalkTiene su propio control de versiones

No muy fácil de integrar con CVS o SVN


FitNesse

Puede vincularse con FIT

Sirve para código Java, Python, C++, .NET y

A3F

Tiene su propio control de versionesNo muy fácil de integrar con CVS o SVN

Concordion

Trabaja como extensión de JUnit=> funciona sólo con JavaCorre bien en conjunto con IDEsMuy amigable para desarrolladores

Se escribe en HTMLRequiere código para vincular especificaciones con tests

41

Requiere código para vincular especificaciones con testsPero no requiere ningún formato como FITRelativamente amigable para perfiles no técnicosSe pueden incluir comentarios y que no los tenga en cuenta

Hay versiones para .NET, Ruby y Python


Concordion

Trabaja como extensión de JUnit

Muy amigable para desarrolladores

Requiere código para vincular especificaciones con tests

A3F

Requiere código para vincular especificaciones con testsPero no requiere ningún formato como FITRelativamente amigable para perfiles no técnicosSe pueden incluir comentarios y que no los tenga en cuenta

Hay versiones para .NET, Ruby y Python

JBehave


=> funciona sólo con Java

Corre bien en conjunto con IDEs


Se escribe texto con el formato “Given… When…

42

Se escribe texto con el formato “Given… When… Then…”

No requiere código para vincular especificaciones con tests

Menos amigable para perfiles no técnicos

Se pueden incluir comentarios y que no los tenga en cuenta

Análogos para Ruby

RSpec

Cucumber, más moderno (¿parecido a Concordion?)


JBehave




A3F


No requiere código para vincular especificaciones con tests

Menos amigable para perfiles no técnicos

Se pueden incluir comentarios y que no los tenga en cuenta

Cucumber, más moderno (¿parecido a Concordion?)

RecursosKent Beck, “Test Driven Development: By Example”

Dan North, “Introducing BDD”, http://blog.dannorth.net/introducing

Dan North, “What´s in a Story”, http://blog.dannorth.net/whats

Eric Evans, “Domain-Driven Design: Tackling Complexity in the Heart of Software”

Andrew Glover, “Is BDD TDD Done Right?”, http://thediscoblog.com/2007/08/28/is-bdd

43

Bertrand Meyer, “Test or spec? Test and spec? http://www.eiffel.com/general/column/2004/september.html

Rick Mugridge y Ward Cunningham, “Fit for Developing Software: Framework for Integrated Tests”

Lasse Koskela, “Test Driven: TDD and Acceptance TDD for Java Developers”

Simon Stewart, “Page Objects”, http://code.google.com/p/selenium/wiki/PageObjects

Gojko Adzic, “Bridging the Communication Gap. Specification by example and agile acceptance testing”


RecursosKent Beck, “Test Driven Development: By Example”

http://blog.dannorth.net/introducing-bdd/

http://blog.dannorth.net/whats-in-a-story/

Driven Design: Tackling Complexity in the Heart of

Andrew Glover, “Is BDD TDD Done Right?”, bdd-tdd-done-right/

A3F

Bertrand Meyer, “Test or spec? Test and spec? Test from spec!”, http://www.eiffel.com/general/column/2004/september.html

Rick Mugridge y Ward Cunningham, “Fit for Developing Software: Framework

Lasse Koskela, “Test Driven: TDD and Acceptance TDD for Java

http://code.google.com/p/selenium/wiki/PageObjects

Gojko Adzic, “Bridging the Communication Gap. Specification by example

1c2011 44


A3F

Cómo seguir

45


Cómo seguir

A3F

Continúa…

Taller de Programación I y IIMucha práctica sobre casos realistas

Análisis de la InformaciónRequisitos y análisis

Técnicas de DiseñoTécnicas de DiseñoProfundización de diseño y DOO

…

1c2011 46


Continúa…

Taller de Programación I y IIMucha práctica sobre casos realistas

Análisis de la Información

A3F

Profundización de diseño y DOO

Más allá de TDD -...

Documents

Transcript of Más allá de TDD -...