TDD – Test Driven Development:
Simplificando algo que não é simples:
Consiste da prática de antes de desenvolver uma funcionalidade, escrever testes unitários (funcionais automatizados! em algumas organizações existem sim testes unitários manuais). É uma prática que auxilia muito no design e na arquitetura de um software e apoia na qualidade aumentando a confiança da equipe que constantemente gera modificações (e/ou refatorações) no código fonte.
STDD – Storytest Driven Development
DDD – Domain Driven-Design
Utilização os mesmos termos para negócio, sistemas, código-fonte, documentação e etc..
FDD – Feature Driven-Development
Consiste em um processo de cinco etapas onde requisitos são analisados e desdobrados em funcionalidades com o planejamento, o detalhamento e a execução orientado por funcionalidades.
BDD – Behaviour Driven-Development
O desenvolvimento orientado ao comportamento se trata de representar de maneira automatizada cenários de negócio e funcionalidades específicas. Pode ser feito a nível unitário, a nível funcional e até atender a requisitos não funcionais de forma automatizada. O importante é que estas suites sejam “vivas”, sejam constantemente atualizadas e acompanhadas ao longo do desenvolvimento local e nos respectivos ambientes e servidores de integração contínua e deploy.
ATDD – Acceptance Testing Driven Development
É uma fusão entre TDD e o BDD. É a escrita de testes automatizados (que podem ser unitários ou não) de critérios de aceite das histórias de usuário que serão desenvolvidas pela equipe ágil de desenvolvimento de software. O vies de BDD é referente ao uso de Linguagens de Domínio Específicas (em inglês: DSL – Domain Specific Language) que traz os jargões, termos e vocabulário utilizado no dia-a-dia pelo negócio para os desenvolvedores e técnicos. Muitas vezes, o formato Gherkin é o utilizado (Given / When / Then com Features e Scenarios).
Agile Coach .Ninja 