Que é o desenvolvemento impulsado por probas, enfoques e vantaxes

Test Driven Development (TDD) é un enfoque de desenvolvemento de software onde se desenvolven casos de proba para especificar e validar o que fará o código.

Practicamente, os casos de proba para cada función créanse e probábanse antes de lanzar o software e, se a proba falla, escríbese novo código (ou reescrito ou parcheado) para pasar a proba e facer que o código sexa sinxelo e sen erros.

O desenvolvemento impulsado por probas (TDD) comeza co deseño e desenvolvemento de probas para cada pequena función dunha aplicación. O cadro TDD instrúe aos desenvolvedores que escriban código novo só se fallou unha proba automatizada. Este enfoque evita a duplicación de código. O módulo TDD completo é un desenvolvemento impulsado por probas.

Test Driven Development (TDD) orixinouse como parte dun paradigma de deseño de software máis amplo coñecido como Extreme Programming (XP), que forma parte da metodoloxía de desenvolvemento de software Agile.

O concepto sinxelo de TDD é escribir e corrixir probas fallidas antes de escribir código novo (antes do desenvolvemento). Isto axuda a evitar a duplicación de código xa que escribimos unha pequena cantidade de código á vez para pasar as probas. (As probas non son máis que condicións esixibles que temos que probar para satisfacelas).

O desenvolvemento baseado en probas é un proceso de desenvolvemento e execución de probas automatizadas antes do desenvolvemento real da aplicación. Por iso, a TDD tamén se chama ás veces Test First Development.

Fases do enfoque TDD

Antes de escribir calquera código novo, o programador debe primeiro crear unha proba unitaria fallida. Entón, o programador, ou parella ou mafia, crea o código suficiente para satisfacer ese requisito. Unha vez superada a proba, o programador pode refactorizar o proxecto, facendo melloras sen cambiar o comportamento.

Aínda que o TDD céntrase nas interaccións do programador a nivel de unidade, hai outros métodos populares, como o desenvolvemento impulsado por probas de aceptación (ATDD) ou o desenvolvemento dirixido por comportamento (BDD), que se centran en probas que poden ser entendidas polos clientes.

Estes métodos implican construír exemplos do mundo real como probas colaborativas entre o persoal de enxeñería e o cliente antes da codificación e, a continuación, executar as probas despois da codificación para demostrar que o código está implementado. Ter as probas coñecidas de antemán mellora a calidade da primeira vez. ATDD e BDD requiren que os desenvolvedores, os probadores e a parte empresarial traballen xuntos para imaxinar e discutir o software e as súas implicacións antes de crear o código.

Vantaxes do TDD

O desenvolvemento baseado en probas pode producir aplicacións de alta calidade en menos tempo do que é posible con métodos máis antigos. A implementación exitosa de TDD require que os desenvolvedores e probadores prevean con precisión como se usarán a aplicación e a súa funcionalidade no mundo real.

TDD constrúe unha serie de probas de regresión como efecto secundario que pode minimizar as probas manuais humanas, atopando problemas antes, o que leva a solucións máis rápidas. A natureza metódica do TDD garante unha cobertura e unha calidade moito máis elevadas que os clásicos ciclos de código por fases > proba > corrixir > reprobar. Dado que as probas realízanse no inicio do ciclo de deseño, o tempo e o diñeiro gastados na depuración posterior redúcense ao mínimo.

Beneficios esperados:

• reducións significativas nas taxas de defectos, a costa dun aumento moderado do esforzo de desenvolvemento inicial
• os gastos xerais son máis que compensados ​​por unha redución do esforzo nas fases finais dos proxectos
• TDD conduce a mellores calidades de deseño no código e, de xeito máis xeral, a un maior grao de calidade "interna" ou técnica, por exemplo, mellorando as métricas de cohesión e acoplamento.

Desvantaxes do TDD

O TDD require unha habilidade considerable para ter éxito, especialmente a nivel de unidade. Moitos sistemas legados simplemente non están construídos tendo en conta as probas unitarias, polo que é imposible illar os compoñentes para probalos.

Ademais, moitos programadores carecen das habilidades para illar e crear código limpo. Todos os membros do equipo deben crear e manter probas unitarias ou quedarán obsoletas rapidamente. E unha organización que mira a TDD terá que investir tempo, ralentizar un pouco agora para ir máis rápido despois.

Finalmente, como ocorre con calquera método, os resultados finais do TDD son tan bos como as probas que se utilizaron, a precisión con que se realizaron e a medida en que imitan as condicións coas que se atopan os usuarios do produto final.

Erros comúns:

• esquecendo realizar probas con frecuencia
• escribir demasiadas probas á vez
• escribir probas que sexan demasiado grandes ou groseiras
• escribir probas demasiado triviais, como omitir aseveracións
• escribir probas para código trivial
• adopción parcial: só uns poucos desenvolvedores nun grupo de traballo usan TDD
• Mantemento deficiente da suite de probas, que normalmente leva a unha suite de probas cun tempo de execución prohibitivo
• suite de probas abandonada (é dicir, raramente ou nunca se executa) - ás veces debido a un mantemento deficiente, ás veces debido á rotación do equipo

Filosofía TDD

TDD permítelle ao programador dar pequenos pasos ao escribir software. A proba escríbese antes de probar a funcionalidade e garante que a aplicación é apta para a probabilidade. Realízase probas nunha pequena cantidade de código para detectar os erros que se producen no código probado. Despois, a funcionalidade é implementada. Isto denomínase "refactor verde vermello" onde o vermello significa un fallo e o verde indica un paso. Estes pasos repítense. O primeiro obxectivo dun programador é centrarse na tarefa que ten a man e superala.

As diferentes etapas implicadas nun ciclo de desenvolvemento impulsado por probas son:

• Engadir unha proba: cada función nova en TDD comeza cunha proba que debe fallar xa que se pon en marcha antes de implementar calquera función. O requisito previo para escribir unha proba antes de implementar a función é unha comprensión clara do requisito por parte do programador. Isto conséguese a través de historias de usuarios e casos de uso. Polo tanto, un programador entende o requisito antes de escribir o código do programa.
• Executa todas as probas e comproba se o novo código falla: isto garante que o arnés de proba funciona correctamente e que a nova proba non falla sen ningún novo código. Este paso tamén verifica a proba e elimina a posibilidade de que a nova proba pase sempre.
• Escribir código: o seguinte paso que segue é escribir o código que borra a proba. O novo código non é perfecto, pero posteriormente modifícase segundo os requisitos. Está deseñado simplemente para probar e non inclúe outras funcións.
• Executa probas automatizadas: se cada caso de proba producido supera a proba facilmente, significa que o código cumpre todas as especificacións requiridas. Despois pódese comezar a fase final do ciclo.
• Código de refactorización: é semellante á eliminación da duplicación. A refactorización non rompe ningunha funcionalidade existente e axuda a eliminar a duplicación entre o código de produción e o de proba. O código agora está limpo segundo se solicitou.
• Repetir: O ciclo repítese como nos casos anteriores cunha nova proba. O requisito esencial é que o tamaño do paso sexa pequeno, con uns 1-10 cambios entre cada proba. Se o novo código falla nunha nova proba, o programador debería facer máis depuración. A integración continua proporciona puntos de control reversibles.

Ercole Palmeri