Desarrollo basado en pruebas in Context

En este captulo se presenta el contexto en el que se est convirtiendo en el desarrollo basado

en pruebas. Se examina una variedad de definiciones para el desarrollo basado en pruebas, y
proporciona un nuevo para los fines de esta investigacin. Se analizan los acontecimientos
histricos y recientes que han contribuido a la comprensin actual de desarrollo basado en
pruebas.
2.1 Definiciones de TDD
Aunque su nombre implicara que TDD es un mtodo de prueba, un examen minucioso del
nombre revela un panorama ms complejo.
2.1.1 Importancia de la "prueba" en TDD
A medida que la primera palabra implica, el desarrollo basado en pruebas se refiere a las
pruebas. En concreto se trata de escribir las pruebas unitarias automatizadas. Prueba de la
unidad es el proceso de aplicacin de las pruebas a las unidades individuales de un programa.
Existe cierto debate en cuanto a qu es exactamente una unidad de software. Incluso dentro
del mbito de la programacin orientada a objetos, tanto la clase y el mtodo se han sugerido
como la unidad apropiada. Generalmente, sin embargo, vamos a considerar una unidad de ser
"la posible componente ms pequeo comprobable software" [21] que en la actualidad [17]
parece ser el mtodo o procedimiento.
Los pilotos de prueba y talones de funciones se implementan con frecuencia para apoyar la
ejecucin de las pruebas unitarias. Ejecucin de la prueba puede ser un proceso manual o
automatizado y puede ser realizado por los desarrolladores o probadores dedicados. Prueba
automatizada de la unidad consiste en escribir las pruebas unitarias como cdigo y colocar el
cdigo en un instrumento de prueba [21] o un marco como JUnit [51]. Marcos automatizados
de pruebas unitarias pueden reducir el esfuerzo de la prueba, incluso para un gran nmero de
pruebas a un botn simple clic. En contraste, cuando la ejecucin de prueba es un proceso
manual, los desarrolladores y / o probadores pueden ser obligados a gastar esfuerzo
significativo proporcional al nmero de pruebas ejecutadas.
6CAPTULO 2. Desarrollo basado en pruebas EN CONTEXTO 7
Tradicionalmente, las pruebas unitarias se ha aplicado algn tiempo despus de que la unidad
ha sido codificado. Este intervalo de tiempo puede ser muy pequeo (unos pocos minutos) o
bastante grande (unos pocos meses). Las pruebas unitarias pueden ser escritos por el mismo
programador o por un probador designado. Con TDD, sin embargo, las pruebas unitarias se
prescriben para ser escrito antes de escribir el cdigo de prueba. Como resultado, las pruebas
unitarias en TDD normalmente no existen por mucho tiempo antes de que se ejecutan.
2.1.2 Significado de "Driven" en TDD
Algunas definiciones de TDD parecen implicar que TDD es principalmente una estrategia de
ensayo. Por ejemplo, de acuerdo con [51] al resumir Beck [17], desarrollo basado en pruebas
(TDD) es una prctica de programacin que instruye a los desarrolladores escribir cdigo
nuevo slo si una prueba automatizada ha fallado, y para eliminar la duplicacin. El objetivo de
TDD es "cdigo limpio que funciona." [45] Sin embargo, de acuerdo con XP y TDD pionera
Ward Cunningham, "Test-primera codificacin no es una tcnica de prueba" [16]. De hecho
TDD va por varios nombres, incluyendo TestFirst Programacin, Diseo Test-Driven y Test-First
Design. El guiado en el desarrollo TestDriven centra en cmo informa TDD y conduce las
decisiones de anlisis, diseo y programacin. TDD asume que el diseo de software est
incompleto, o al menos muy flexible y abierto a los cambios evolutivos. En el contexto de XP,
TDD incluso subsume muchas decisiones de anlisis. En XP, el cliente es supuestamente "in
situ", y la escritura de ensayo es uno de los primeros pasos en la decisin de lo que el
programa debe hacer, que es esencialmente una etapa de anlisis. Otra definicin que capta
esta idea proviene de la Agile Alliance [7], el desarrollo basado en pruebas (TDD) es el arte de
la produccin de pruebas automatizadas para cdigo de produccin, y el uso de este proceso
para impulsar el diseo y la programacin. Por cada poco de la funcionalidad en el cdigo de
produccin, primero desarrollar una prueba que especifica y valida lo que el cdigo va a hacer.
A continuacin, producir exactamente tanto el cdigo que le permita pasar esa prueba. A
continuacin, refactorizar (simplificacin y clarificacin) tanto en el cdigo de produccin y el
cdigo de prueba. Como se ve en esta definicin, la promocin de los ensayos a un anlisis y
diseo de paso implica la prctica importante de refactorizacin [29]. Refactoring es una
tcnica para cambiar la estructura de un cuerpo de cdigo existente sin cambiar su
comportamiento externo. Una prueba puede pasar, pero el cdigo puede ser inflexible o
demasiado compleja. Por refactorizacin del cdigo, la prueba debe todava pasar y se
mejorar el cdigo.
Entendiendo que TDD es ms sobre el anlisis y el diseo de lo que se trata de pruebas puede
ser uno de los cambios conceptuales ms difciles para los nuevos adoptantes de la prctica.
Como se discutir ms adelante, las pruebas han asumido tradicionalmente la existencia de un
programa. La idea de que una prueba puede ser escrito antes del cdigo, y ms an, que la
prueba puede ayudar a decidir cul es el cdigo para escribir y lo que su interfaz debe ser
similar es un concepto radical para la mayora developers.CHAPTER software 2. Desarrollo
basado en pruebas EN CONTEXTO 8
2.1.3 Importancia del "desarrollo" en TDD
TDD est destinado a ayudar a la construccin de software. TDD no es en s una metodologa
de desarrollo de software o modelo de proceso. TDD es una prctica, o una forma de
desarrollo de software para ser utilizado en conjuncin con otras prcticas en una orden y
frecuencia particular en el contexto de algn modelo de proceso. Como veremos en la
siguiente seccin, TDD se ha convertido en un conjunto particular de modelos de procesos.
Parece posible que TDD podra aplicarse como un micro-proceso en el contexto de muchos
modelos de procesos diferentes.
Hemos visto que TDD tiene que ver con el anlisis y el diseo. No queremos pasar por alto el
hecho de que TDD tambin produce un conjunto de pruebas unitarias automatizadas que
ofrecen una serie de efectos secundarios en el proceso de desarrollo. TDD asume que estas
pruebas automatizadas no se desechan una vez que se tome una decisin de diseo. En
cambio, las pruebas se convierten en un elemento esencial del proceso de desarrollo. Entre los
beneficios, el conjunto de pruebas automatizadas proporcionar informacin rpida a los
cambios en el sistema. Si un cambio provoca un error de la prueba, el desarrollador debe saber
en cuestin de minutos de hacer el cambio, mientras que todava est fresco en su mente.
Entre los inconvenientes, el desarrollador tiene ahora tanto el cdigo de produccin y las
pruebas automatizadas que deben mantenerse.
2.1.4 Una nueva definicin de TDD
Definiciones TDD propuestos hasta la fecha suponer un diseo sin especificar y un compromiso
para escribir pruebas automatizadas para todo el cdigo de produccin no trivial. A pesar de la
promesa de ofrecer "un cdigo limpio que funciona" de TDD, muchos desarrolladores parecen
ser reacios a probar TDD. Esta reticencia es quizs al menos parcialmente una consecuencia de
la eleccin del proceso de desarrollo en general en una organizacin. Obviamente, una
organizacin que est aplicando XP est dispuesto a intentar TDD. Sin embargo, una
organizacin que utiliza un enfoque ms tradicional es probable que no pueda ver cmo TDD
puede caber. Este y otros factores que afectan a esta opcin ser ms completamente en el
captulo tres.
Para ampliar la utilidad y aplicabilidad de TDD, propongo la siguiente modificacin de la
definicin Agile Alliance: el desarrollo basado en pruebas (TDD) es una estrategia de desarrollo
de software que requiere que las pruebas automatizadas pueden escribir antes de escribir
cdigo funcional en pequeas iteraciones rpidas. Por cada poco de la funcionalidad deseada,
primero desarrollar una prueba que especifica y valida lo que el cdigo va a hacer. A
continuacin, producir exactamente tanto el cdigo que le permita pasar esa prueba. A
continuacin, refactorizar (simplificacin y clarificacin) tanto el cdigo bajo prueba y el cdigo
de prueba. Desarrollo basado en pruebas se puede utilizar para explorar, disear, desarrollar y
/ o software de prueba.
Esta definicin se ampla el mbito de TDD de influencia por lo que sugiere que TDD se puede
utilizar para: CAPTULO 2. Desarrollo basado en pruebas EN CONTEXTO 9
Explorar un diseo determinado o indeterminado
Explorar un componente nuevo o desconocido
Software de diseo
Desarrollar software dado un diseo
Desarrollar pruebas de software dado slo su interfaz
Esta definicin elimina las restricciones de trabajo en un diseo sin especificar y trabajando
slo en el cdigo de produccin. Se introduce la posibilidad de que el DDT podra ser utilizado
como un mecanismo de creacin de prototipos para la elaboracin de un diseo posible, sin
necesidad de las pruebas a quedarse.
2.2 Estudio de las metodologas de desarrollo de software
El resto de este captulo se analiza el contexto en el que ha contribuido a la aparicin de
desarrollo basado en pruebas. En esta seccin se ofrece un amplio estudio de las metodologas
de desarrollo de software para ayudar a establecer un fondo para el desarrollo TestDriven
comprensin. Un proceso de desarrollo de software o la metodologa es un marco que define
un orden en particular, el control y la evaluacin de las tareas bsicas que intervienen en la
creacin de software. Metodologas de procesos de software varan en complejidad y el
control de gran parte informal altamente estructurado. Las metodologas pueden ser
clasificados como prescriptivo [63] o giles [14], y etiquetados con nombres como cascada
[66], espiral [19], incremento [63] y la evolucin [35].
Cuando una organizacin de estados que utiliza una metodologa en particular, a menudo se
aplican en un proyecto de escala determinadas combinaciones de metodologas ms
pequeos, de grano ms fino. Por ejemplo, una organizacin puede estar aplicando un modelo
gradual de desarrollo, la construccin de sectores pequeos y acumulativos de las
caractersticas del proyecto. En cada incremento sin embargo, pueden estar aplicando una
cascada lineal o mtodo de determinacin de los requisitos, el diseo de una solucin,
codificacin, la prueba y, a continuacin integrar. Dependiendo del tamao de los incrementos
y el marco de tiempo de la cascada, el proceso puede ser marcado de manera muy diferente,
posiblemente, con resultados muy diferentes con respecto a la calidad y la satisfaccin del
desarrollador.
Si rompemos un proyecto de software en incrementos de N en cada incremento se representa
como 1, entonces todo el proyecto podra ser representada por la ecuacin! Ni = 1ii. Si N es
bastante grande, entonces podramos etiquetar este proyecto como un proyecto progresivo.
Sin embargo, si N 2, entonces probablemente etiquetar esto como un proyecto cascada. Si
los incrementos requieren la modificacin de una cantidad significativa de software de
superposicin, entonces podramos decir que nuestra metodologa es ms iterativo en la
naturaleza. Dicho con ms cuidado, para el proyecto P consiste en cdigo C y I = iteraciones! Ni
= 1ii, si Ci isCHAPTER 2. Desarrollo basado en pruebas EN CONTEXTO 10 del cdigo afectado
por iteracin II, a con nuacin, si el proyecto P es itera vo, Ci Ci 1 "= para la mayora de i
tal que 1 <i <N. Del mismo modo, con los enfoques graduales y cascada, que podra esperar un
artefacto formal (tal como un documento de especificacin) para los requisitos de
documentingthe para que incremento. Si sin embargo, el artefacto es ms bien informal
(algunos dibujos pizarra o un conjunto incompleto de diagramas UML), y se gener de forma
relativamente rpida, entonces es probable que estbamos trabajando en el contexto de un
proceso gil. O bien, el enfoque y la perspectiva de la arquitectura y / o diseo pueden hacer
que nos etiquetamos el proceso orientado a aspectos, basado en componentes, o la funcin de
motor. Profundizando an ms , podramos encontrar que los desarrolladores de software
individuales o equipos pequeos estn aplicando incluso los modelos de grano ms fino como
el Proceso de Software Personal [42] o el Proceso de Software de Colaboracin [73]. La hora, la
formalidad, y la interseccin de los pasos en la construccin de software puede determinar la
forma en que se clasifica la metodologa del proceso.
Alternativamente, el orden en el que ocurren las tareas de construccin influye en la etiqueta
de un proyecto, y es probable que su calidad. El orden tradicional es el levantamiento de
requerimientos, anlisis, diseo, cdigo, pruebas, integracin, despliegue, mantenimiento.
Este orden es muy natural y lgico, sin embargo, podemos considerar algunas re-
ordenamientos posible. La mayora de los reordenamientos no tienen sentido. Por ejemplo,
nunca mantener un sistema que no se ha codificado. Del mismo modo, nunca codificar algo
para lo que no tenemos necesidades. Tenga en cuenta que los requisitos no necesariamente
implican requisitos formales, pero puede ser tan simple como una idea en la cabeza de un
programador. El enfoque de prototipos [20] se ha aplicado cuando las necesidades son
confusos o incompletos. Con este enfoque, podemos hacer muy poco anlisis y diseo antes
de la codificacin. La desventaja es que el prototipo es a menudo descartada a pesar de que
era una herramienta til en la determinacin de los requisitos y la evaluacin de las opciones
de diseo. Cuando examinamos de cerca las fases como el diseo, el cdigo y la prueba, vemos
que hay muchas actividades de grano ms fino. Por ejemplo, hay muchos tipos de pruebas:
pruebas unitarias, pruebas de integracin, y pruebas de regresin entre otros. El tiempo, la
frecuencia, y la granularidad de estas pruebas pueden variar ampliamente. Puede ser posible
llevar a cabo algunas pruebas temprana, concurrente con otras actividades de codificacin.
Desarrollo basado en pruebas, sin embargo, los intentos de volver a pedir estos pasos para
algn tipo de ventaja. Mediante la colocacin de las pruebas de grano muy fino de la unidad
justo antes de cdigo slo lo suficiente para satisfacer esa prueba, TDD tiene el potencial de
llevar a cabo muchos aspectos de una metodologa de desarrollo de software.
2.3 Contexto histrico de TDD
Desarrollo basado en pruebas se ha convertido junto con el surgimiento de modelos de
procesos giles. Ambos tienen sus races en el iterativo, incremental y modelos de procesos
evolutivos, que se remonta al menos desde la dcada de 1950. Adems, las herramientas han
evolucionado y ha surgido para jugar un papel importante en el apoyo de TDD. Curriculum
parece quedarse en su adopcin de TDD, XP, pero en general se ha visto un poco de atencin
favorable en theCHAPTER 2. Desarrollo basado en pruebas EN CONTEXTO 11 comunidad
acadmica.
2.3.1 Los primeros ejemplos de los ensayos tempranos
Investigacin en general, los ensayos ha asumido la existencia de un programa a ser probado
[37], lo que implica una prueba-ltimo enfoque. Mover las pruebas, sin embargo, desde el final
de la codificacin al principio no es nada nuevo. Es comn que los equipos de software y
pruebas para desarrollar las primeras pruebas en el proceso de desarrollo de software, a
menudo junto con la lgica del programa.
Evaluacin y Prevencin del Ciclo de Vida modelos [33] prueba integrada pronto en el proceso
de desarrollo de software casi dos dcadas atrs. Introducido en la dcada de 1980, la sala
blanca [27] enfoque de la ingeniera de software incluye la verificacin formal de elementos de
diseo al principio del proceso de desarrollo. Incluso hay afirmaciones de que alguna forma de
TDD se aplic ya en la dcada de 1950 en el Proyecto Mercury de la NASA [48]. Sin embargo,
antes de la introduccin de XP en 1998, muy poco o nada se ha escrito sobre el concepto de
dejar pequeas pruebas unitarias automatizadas incrementales impulsan el desarrollo de
software y sobre todo el proceso de diseo. A pesar de la falta de documentacin publicada, es
muy posible que muchos desarrolladores han utilizado una primera aproximacin de prueba
informal. Kent Beck incluso afirma que aprendi previamente probado programacin como un
nio leyendo un libro sobre programacin. Dijo que se programa tomando la cinta de entrada
... y escribir en la cinta de salida que espera. A continuacin, el programa hasta que obtenga la
cinta de salida que espera. [16] Se podra argumentar entonces que TDD limita a recordar su
nombre y la definicin de una prctica que se ha aplicado de forma espordica e informal
desde hace algn tiempo. Parece, sin embargo, que TDD es un poco ms que eso. Como dice
Beck, XP tiene las mejores prcticas conocidas y "convierte a los mandos de todo el camino
hasta el diez." En otras palabras, en el extremo. Muchos desarrolladores pueden haber
estado pensando y codificacin en una prueba de primera clase, pero TDD hace esto de una
manera extrema, por siempre escribir las pruebas antes del cdigo, por lo que las pruebas lo
ms pequeo posible, y nunca dejar que el cdigo se degradan (test, cdigo, refactorizar).
Como veremos a continuacin, TDD es una prctica que debe encajar dentro de un modelo de
proceso. El desarrollo de los incrementales, iterativos y modelos de procesos evolutivos ha
sido vital para el surgimiento de TDD.
2.3.2 incremental, iterativo y desarrollo evolutivo
Larman y Basili [48] Estudio de una larga histo iterativos y modelos de desarrollo incremental.
El desarrollo iterativo implica la repeticin de un conjunto de tareas de desarrollo,
generalmente en un conjunto de requisitos de expansin. Enfoques evolutivos como se
presentan por primera vez por Gilb [35] implica el desarrollo, que es adaptable y ligero
iterativo. Ser adaptable generalmente se refiere a la utilizacin de la retroalimentacin de las
iteraciones anteriores para mejorar andCHAPTER 2. Desarrollo basado en pruebas EN
CONTEXTO 12 cambiar el software en la iteracin actual. Ser ligero a menudo se refiere a la
falta de una especificacin completa al comienzo del desarrollo, lo que permite la
retroalimentacin de iteraciones anteriores y de los clientes para guiar futuras iteraciones.
Ligero puede referirse a otros aspectos tales como el nivel de formalidad y el grado de
documentacin en un proceso. El modelo en espiral [19] es un enfoque evolutivo que
incorpora prototipos y la naturaleza cclica de desarrollo iterativo, junto con "riesgo-
driveniterations" y "punto de anclaje" hitos Segn Pressman [63], el modelo incremental de
entrega de una serie de versiones, llamado incrementos, que ofrecen cada vez ms
funcionalidad para el cliente que se entrega cada incremento.
Fue en el contexto de tales iterativo, incremental y evolutivo modelos que TDD desarrollado.
De hecho, parece que tales iterativo, incremental y / o enfoques evolutivos son modelos de
procesos de requisitos previos que son necesarios para TDD para trabajar. Como hemos dicho,
TDD est ms estrechamente relacionada con XP que es un proceso iterativo, el modelo
evolutivo. De hecho, Beck afirma que con el fin de implementar XP, debe aplicar todas las
prcticas tradicionales. Dejando un poco fuera debilita el modelo y puede hacer que el modelo
al fracaso [15]. Para TDD para influir en el diseo de software, TDD requiere que las decisiones
de diseo se retrasen y flexible. Con cada nueva prueba, algo nuevo se manifieste sobre el
cdigo que requiere una refactorizacin y el posible cambio en el diseo segn lo determinado
en ese momento. Las pruebas automatizadas dan el coraje programador para modificar el
cdigo y saber rpidamente si algo se ha roto, lo que permite la propiedad colectiva. Como se
propuso originalmente, TDD requiere alguna forma de un modelo de proceso evolutivo. Lo
contrario, sin embargo, no es totalmente cierto ya que muchos iterativo, incremental y / o
modelos evolucionistas han propuesto sin la mencin de TDD.
2.4 La aparicin de herramientas de pruebas automatizadas
Las herramientas de software se han convertido en factores importantes en el desarrollo de
sistemas informticos modernos. Herramientas que van desde los compiladores, depuradores,
y entornos de desarrollo integrados (IDEs) a travs del modelado y la ingeniera de software
asistida por ordenador (CASE) herramientas han mejorado y aumentado por lo tanto
significativamente la productividad del desarrollador. Del mismo modo las herramientas de
prueba han madurado a lo largo de los aos.
Las herramientas de prueba varan en propsito y alcance, y no sern revisados aqu. Sin
embargo, es importante tener en cuenta el papel que las herramientas han jugado en la
aparicin de TDD. TDD supone la existencia de un marco de pruebas unitarias automatizadas.
Dicho marco simplifica la creacin y ejecucin de pruebas unitarias de software. Arneses de
prueba son, bsicamente, los marcos de pruebas automatizadas y han existido durante algn
tiempo. Un instrumento de prueba es una combinacin de los pilotos de pruebas, talones, y,
posiblemente, interfaces con otherCHAPTER 2. Desarrollo basado en pruebas EN CONTEXTO
13 subsistemas [21]. A menudo, estos arneses son a la medida, a pesar de las herramientas
comerciales existen para ayudar en la preparacin de instrumento de prueba [62]. JUnit [31] es
un marco de pruebas unitarias automatizadas para Java desarrollado por Erich Gamma y Kent
Beck. JUnit es una herramienta esencial para la aplicacin de TDD con Java. De hecho, se
podra argumentar que TDD e incluso XP podran no haber recibido esa gran popularidad, si no
fuera por JUnit. Marcos JUnit similares se han implementado para un nmero de diferentes
idiomas, y la familia de los marcos se denomina xUnit [76].
Generalmente, xUnit permite al programador escribir conjuntos de pruebas unitarias
automatizadas, que inicializan, ejecutan y hacen afirmaciones sobre el cdigo de prueba. Las
pruebas individuales son independientes el uno del otro para que el orden de prueba no
importa, y el nmero total de los xitos y los fracasos son reportados. pruebas xUnit estn
escritos en el mismo idioma que el cdigo de prueba y por lo tanto sirven como clientes de
primera clase del cdigo. Como resultado, las pruebas pueden servir como documentacin
para el cdigo. Por otro lado, debido a xUnit se implementa en el idioma de destino, la
sencillez y la flexibilidad de la herramienta se determinan en parte por ese idioma. Por ejemplo
JUnit es muy sencillo y porttil, en parte porque se aprovecha de la portabilidad de Java a
travs del cdigo de bytes / arquitectura de la mquina virtual, que utiliza la capacidad de Java
para cargar clases de forma dinmica, y explota mecanismo de reflexin de Java para detectar
automticamente las pruebas. Adems, ofrece una interfaz agradable, portable grfica de
usuario que incluso se ha integrado en los entornos de desarrollo integrados populares como
Eclipse. Una amplia gama de herramientas adicionales han surgido para apoyar las pruebas
automatizadas, particularmente en Java. Varias herramientas intentan simplificar la creacin
de objetos de imitacin [9], que son esencialmente los trozos que se destacan en la
colaboracin necesaria para los objetos de manera que slo se puede probar un objeto en
particular. Otras herramientas tales como Cactus [10] y Derby [11] se puede utilizar en
conjuncin con JUnit para automatizar pruebas que implican componentes J2EE o bases de
datos, respectivamente.
La proliferacin de herramientas de software de apoyo TDD parece ser un indicador de que
TDD tiene un amplio apoyo, y puede estar en camino de convertirse en un mtodo
establecido. Un factor significativo en el uso de TDD en particular en la comunidad de Java
parece ser la simplicidad y la elegancia de la herramienta JUnit. Los programadores pueden
desarrollar la unidad de pruebas con facilidad, y las grandes suites de pruebas se pueden
ejecutar con un solo clic de un botn, proporcionando resultados rpidos en el estado del
sistema.
2.5 Las primeras pruebas en Currculo
Un indicador de la aceptacin generalizada de una prctica de software podra ser el plan de
estudios de licenciatura en ciencias de la computacin e ingeniera de software. En algunos
casos, la academia ha llevado a la prctica en el campo. En los dems, el mundo acadmico ha
seguido.
Ingeniera de Software, desarrollo iterativo y TDD parecen todos caen en esta ltima
model.CHAPTER 2. Desarrollo basado en pruebas EN CONTEXTO 14 Aunque muchas
investigaciones de ingeniera de software se ha originado en el mundo acadmico, y encontr
su camino en la prctica comn, el plan de estudios de licenciatura en ciencias de la
computacin e ingeniera de software ha tendido a reflejar y la zaga de la prctica comn en la
industria. Programacin Idiomas ha seguido habitualmente las necesidades de las empresas.
Los modelos de proceso se han desarrollado en la prctica y, posteriormente, han reflejado en
los planes de estudios.
Las directrices Curriculum 1991 ACM [5] recomienda que una pequea cantidad de
conferencia y tiempo de laboratorio se dar a los procesos de desarrollo iterativo (SE2) y la
verificacin y validacin (SE5) (porciones a ocho horas cada uno). Las Directrices Curriculares
ACM 2001 [6] recomienda una cantidad incluso ms pequea de tiempo se dar a los procesos
de desarrollo (SE4) y la validacin de software (SE6) (dos y tres horas, respectivamente).
Textos Pregrado dan poca atencin a los modelos de procesos comparativos. Los textos tienen
una cobertura limitada del diseo de software y suelen tener una cobertura mnima de las
tcnicas de prueba. Los temas de diseo de software y pruebas son a menudo relegados a un
curso de ingeniera de software que no pueden ni siquiera se requiere de todos los
estudiantes. Hay un gran debate sobre el lugar de la Programacin Extrema en la educacin
universitaria. Algunos [39] argumentan fuertemente en favor del uso de XP para introducir a
los estudiantes de ingeniera de software. Otros [67] argumentan que los mtodos XP y gil
slo son beneficiosos en forma muy limitada. Y otros [59] Informe de experiencias variadas.
A pesar de la mezcla de opiniones sobre el uso de XP en el plan de estudios, TDD est
recibiendo cierta exposicin limitada a este nivel. Algunos educadores han llamado para una
mayor diseo y la cobertura de las pruebas por un tiempo. Algunos ven TDD como una
oportunidad para incorporar las pruebas de todo el plan de estudios, y no relegarlo a un curso
individual [22].
Herramientas TDD han encontrado su camino en la educacin temprana de programacin.
BlueJ [47], un medio popular para el aprendizaje de Java ha incorporado JUnit y ha aadido
ayuda para la creacin de casos de prueba en una etapa temprana en el ciclo de aprendizaje
de un programador [61]. JUnit se ha defendido para el aprendizaje temprano de Java, ya que
abstrae la ofMain mecanismo de bootstrapping (), lo que permite al estudiante concentrarse
en el uso de los objetos antes de tiempo. TDD, sin embargo, an est lejos de ser ampliamente
aceptado en el mundo acadmico. Facultad que no se especializan en ingeniera de software
siguen siendo poco probable que tenga mucha familiaridad con TDD. Materiales didcticos
sobre TDD dirigidas a estudios de grado son bsicamente inexistente. Como veremos en el
captulo cinco, varios pasos deben realizarse antes de TDD encuentra su lugar en el plan de
estudios.
2.6 Contexto reciente del TDD
Desarrollo basado en pruebas ha surgido en el contexto de los mtodos giles. En esta seccin
se destaca la importancia de los mtodos giles y considera los intentos de medir la cantidad
de grupos de desarrollo estn aplicando methods.CHAPTER gil 2. Desarrollo basado en
pruebas EN CONTEXTO 15
2.6.1 La aparicin de mtodos giles
Los primeros aos del siglo XXI han visto significativa atencin a lo que son
deemedagilemethods. Los mtodos giles claramente tienen sus races en el incremento
iterativo y mtodos evolutivos discutidos anteriormente. Abrahamsson et al. [4] proporcionar
un mapa evolutivo de nueve mtodos giles, y describir tales mtodos como se centra
principalmente en la simplicidad y la velocidad, haciendo hincapi en las personas mayores de
procesos [3].
Extreme Programming (XP) [15] es probablemente el mtodo ms conocido gil, y de hecho XP
se utiliza a menudo en combinacin con otros mtodos giles como Scrum. XP propone el uso
de DDT como un componente integral del desarrollo de software de alta calidad. Hay un
interesante conflicto entre la prctica altamente disciplinado de TDD y la naturaleza simple,
ligero de los procesos giles. De hecho, una de las principales preocupaciones de los
potenciales adoptadores de TDD parece ser la sobrecarga o el coste / tiempo de la escritura y
el mantenimiento de la unidad de pruebas. A pesar de que admite que las pruebas unitarias
automatizadas no son necesarios para absolutamente todo (algunas cosas siguen siendo
difciles de probar de forma automtica), Beck insiste en que TDD es necesario para XP
funcione. Parece que TDD puede proporcionar el "pegamento" que mantiene el proceso en
conjunto.
2.6.2 Adopcin de medicin de los Mtodos giles Es difcil medir el uso de una metodologa
particular, el desarrollo de software.
Muchas organizaciones pueden estar utilizando la metodologa, pero no hablar de ello. Otros
podran alegar que el uso de una metodologa, cuando en realidad pueden ser mal aplicando la
metodologa, o peor an, la publicidad de su uso falsamente. Las encuestas pueden llevarse a
cabo para evaluar el uso de mtodos, pero a menudo slo aquellos que son entusiastas acerca
de la metodologa (ya sea a favor o en contra) respondern.
Un estudio de 2002 [65] inform de que de los 32 encuestados en diez segmentos de la
industria, catorce empresas estaban utilizando un proceso gil. De ellos, cinco de las empresas
se clasificaron en la industria de E-business. La mayora de los proyectos mediante procesos
giles eran pequeas (diez o menos participantes) y una duracin de un ao o menos. Otro
estudio de 2003 [68] inform de 131 encuestados que afirman que estaban usando un mtodo
gil. De stos, el 59% afirm estar usando XP, lo que implica que ellos estaban usando TDD.
Ambos estudios revelaron resultados positivos de la aplicacin de los mtodos giles con el
aumento de la productividad y la calidad, y los cambios menores o mnimos en los costos. Un
importante cuerpo de literatura sobre XP se ha acumulado desde su creacin. La mayor parte
de esta literatura sin duda implica la promocin de XP o explicaciones de cmo implementar
XP. Muchos informes de experiencias presentes slo evidencia anecdtica de los beneficios y
desventajas de XP. Sin embargo, su existencia indica que XP est siendo adoptado en muchas
organizaciones. Todava no est claro si estas mismas organizaciones continuarn utilizando XP
con el tiempo, o si tienen o se trasladar a otros mtodos (o viejo).
No tenemos conocimiento de ninguna medida de cun extendido es el uso de TDD. La
popularidad de XP, sin embargo, parece implicar una creciente adopcin de TDD. Es
possibleCHAPTER 2. Desarrollo basado en pruebas EN CONTEXTO 16 que las organizaciones
estn adoptando XP sin necesidad de adoptar todas las prcticas, o que estn aplicando
algunas prcticas de manera inconsistente. Informes Rasmusson en un proyecto en
ThoughtWorks, uno de los primeros de XP, en el que se estima que una tercera parte del
cdigo fue desarrollado utilizando TDD [64]. En el mismo informe, sin embargo, afirma, si
pudiera slo recomendara una prctica de codificacin para los desarrolladores de software,
los que usan XP o de lo contrario, habra que escribir las pruebas unitarias. En este proyecto
ThoughtWorks, 16.000 lneas de pruebas unitarias automatizadas fueron escritas para 21.000
lneas de cdigo de produccin. Parece que muchas pruebas fueron escritos en un banco de
pruebas primera y ltima prueba-forma.
A pesar de la posibilidad de adoptar XP sin TDD, TDD parece ser una prctica fundamental en
XP y la evidencia anecdtica parece indicar que TDD se incluye comnmente cuando se adopta
slo un subconjunto de XP.
Otro posible indicador de la utilizacin de TDD es el uso de los marcos de las pruebas xUnit.
JUnit fue el primer marco y ha disfrutado de una gran popularidad. Como Martin Fowler dijo
sobre JUnit, Nunca en el campo del desarrollo de software se lo han debido tanto a tan pocas
lneas de cdigo [31].
No hay estadsticas de adopcin son directamente disponible para JUnit. Sin embargo, JUnit
est incluido en la distribucin principal de Eclipse, un entorno de desarrollo integrado muy
popular que se utiliza principalmente para el desarrollo Java. A febrero de 2004 comunicado
de prensa [23] afirma que la plataforma Eclipse ha grabado ms de 18 millones de solicitudes
de descarga desde su creacin. Aunque probablemente se producen solicitudes duplicadas del
mismo desarrollador solicitando nuevos lanzamientos, la cifra sigue siendo considerable.
Ciertamente, no todos los desarrolladores de Eclipse estn utilizando JUnit, ni son todos los
adoptantes JUnit utilizando TDD, pero parece probable que la combinacin de XP, JUnit y
Eclipse popularidad implica cierto grado de adopcin TDD.