UNIVERSIDADE ANHEMBI MORUMBI

CAMPUS VILA OLIMPIA

SISTEMAS DE INFORMAÇÃO
PRÁTICAS DE ENGENHARIA DE SOFTWARE

ATIVIDADE PRÁTICA SUPERVISIONADA

Laura Inocencio de Andrade

RA 21210165
Sumário

1. Introdução ............................................................................................................................... 3

2. Sistemas de Desenvolvimentos (BDD, TDD, ATDD e DDD) .............................................. 4

2.1 Test Driven Development (TDD) ..................................................................................... 4

2.2 Behaviour Driven Development (BDD) ........................................................................... 5

2.3 Domain Driven Development ou Domain Driven Design (DDD) ................................... 6

2.4 Acceptance Test-Driven Development (ATDD) .............................................................. 7

3.Testes Funcionais utilizando a semântica do BDD ................................................................. 8

3.1 Cenário: “Esqueci minha senha” na plataforma do Outlook (Restauração de senha) ...... 8

3.2 Cenário: Compra no eCommerce ..................................................................................... 9

3.3 Cenário: Novo usuário no Twitter .................................................................................... 9

4. Conclusão ............................................................................................................................. 10

5. Referências Bibliográficas .................................................................................................... 11

1. Introdução

Neste documento será realizada uma pesquisa com exemplos sobre as boas práticas de
desenvolvimento, testes ágeis, testes funcionais, padrões de arquitetura e de projetos, que
abordam os tópicos BBD (Behavior Driven Development), TDD (Test Driven Development),
as principais diferenças entre BDD e TDD, ATDD (Acceptance Test Driven Development) e
DDD (Domain Driven Development ou Domain Driven Design).

3
2. Sistemas de Desenvolvimentos (BDD, TDD, ATDD e DDD)

Quando se estuda Engenharia de Software, aprende-se que todo sistema tem um tempo
de vida útil, e que uma série de fatores podem contribuir para aumentar ou diminuir este tempo:
arquitetura, modelagem, tecnologia utilizada, aceitação do mercado, etc. No entanto, nenhuma
empresa desenvolve um sistema pensando no dia em que ele deixará de atender as necessidades
do seu cliente, apesar desta ser uma verdade certa.
Neste ciclo, o sistema passa a maior parte do tempo sofrendo alterações. E estas
manutenções, sejam elas corretivas ou não, podem melhorar ou piorar o sistema, dependendo
da forma que forem implementadas. Pensando neste e em outros problemas, Kent Beck
apresentou ao mundo em 2003, através do seu livro “Test-Driven Development”, uma técnica
para criar sistemas baseados em testes que visa garantir a qualidade e a funcionalidade do
software durante este ciclo.
Embora TDD seja uma técnica testada e aprovada por grandes desenvolvedores ágeis,
muitas equipes de desenvolvimento ainda caem em algumas armadilhas e mal-entendidos do
tipo: por onde começar, o que testar e o que não testar. Isto sem falar que quem escreve os testes
são os desenvolvedores, mas quando a equipe de qualidade vai testar, ela se preocupa com o
comportamento do sistema e não com os testes unitários. Desta forma, não há comunicação
eficiente entre as duas equipes no nível de código. Mas o que seria o TDD?

2.1 Test Driven Development (TDD)

Test Driven Development (TDD) ou, em português, Desenvolvimento Dirigido por

Testes é uma técnica de desenvolvimento de software que se baseia em um ciclo curto de
repetições. Primeiramente o desenvolvedor escreve um caso de teste automatizado que define
uma melhoria desejada ou uma nova funcionalidade. Então, é produzido código que possa ser
validado pelo teste. Posteriormente este código será refatorado para colocá-lo sob padrões
aceitáveis, ou seja, este tipo de desenvolvimento deve seguir algumas etapas importantes,
iniciando com a escrita de um teste mesmo que ainda não tenha o código do sistema em mãos.
Este script de teste será realizado algumas vezes durante o desenvolvimento conforme
necessidade, buscando a maior qualidade possível do código final.
O Ciclo de realização desta metodologia ágil é simples, funcionando da seguinte
maneira: Criação de um teste automatizado, codificação para passar no teste e refatoração do
código.

4
 Além disso, todos os testes devem seguir o modelo F.I.R.S.T ( fast - rápidos, isolated -
testes unitários são feitos de forma isoladas, repeatable - repetição nos testes, self verifying -
verificação de falhas, timely - o teste deve ser oportuno, sendo um teste por unidade).
Kent Beck declarou em 2003 que TDD encoraja designs de código simples e inspira
confiança. Do ponto de vista de Robert C. Martin, escritor do livro “Agile Software
Development”, o objetivo de TDD é a especificação e não a validação, ou seja, é a maneira de
pensar através das necessidades do projeto antes de escrever o código funcional.

Para tornar a aplicação de TDD mais simples e ajudar as equipes de desenvolvimento a

resolverem as questões mencionadas acima, surgiu o Behaviour Driven Development (BDD).
Neste artigo, veremos como aplicar esta técnica de forma eficiente, utilizando os frameworks
mais conhecidos da comunidade Java.

2.2 Behaviour Driven Development (BDD)

O BDD é uma técnica de desenvolvimento que integra a parte técnica de linguagens de

programação com a parte de regras de negócios, podendo-se dizer que é a evolução do modelo
TDD citado anteriormente, pois ambas são orientadas por testes antes da própria escrita do
código.
Este método de desenvolvimento possui inúmeras vantagens, entre elas a comunicação
entre equipes, possibilitando o trabalho em conjunto entre a equipe de desenvolvimento e a
equipe de testes, o compartilhamento de conhecimento entre as duas equipes e uma
documentação muito mais dinâmica.
BDD ajuda a simplificar toda a comunicação dos possíveis cenários propostos pelo
cliente e cada cenário é dividido em três etapas/blocos com as seguintes palavras chaves: Given
(dado um contexto), When (quando ocorre um determinado evento) e Then (execução do
evento).

5
 Vantagens em usar BDD

Quando Dan North fala sobre BDD, ele sempre esclarece que o propósito não é anular
as práticas de TDD, muito pelo contrário, é adicionar a elas uma série de outras vantagens,
dentre as quais se podem listar:
Comunicação entre equipes: na maioria das empresas de desenvolvimento de software
é difícil fazer com que desenvolvedores e testadores trabalhem em conjunto para atingir um
objetivo. BDD possibilita esta integração porque os testadores podem escrever os cenários de
testes para os desenvolvedores implementarem;
Compartilhamento de conhecimento: com desenvolvedores e testadores trabalhando
juntos, ao longo do tempo, um irá transferir o seu conhecimento para o outro, criando assim
uma equipe multifuncional;
Documentação dinâmica: algumas equipes ágeis afirmam que não documentam o
sistema porque a manutenção destes artefatos é custosa. Usando os frameworks de BDD estes
artefatos são gerados dinamicamente sem nenhum esforço adicional. Alguns, inclusive, geram
relatórios em formato HTML, o que irá facilitar uma consulta posterior;
Visão do todo: Fergus O’Connell, em sua obra “How to Run Successful High-Tech
Project-Based Organizations”(Artech House, 1999), apresenta uma relação dos principais
motivos que levamprojetos de software ao fracasso. O primeiro deles é: “os objetivos do projeto
não são bem definidos e compartilhados entre todos os envolvidos”. Por este motivo, BDD
sugere que os analistas/testadores escrevam os cenários antes mesmo dos testes serem
implementados, e desta forma os desenvolvedores terão uma visão geral do objetivo do projeto
antes de codificá-lo.

2.3 Domain Driven Development ou Domain Driven Design (DDD)

Já o DDD (Domain Driven Development ou Domain Driven Design) trata-se de uma

metodologia de design de software que tem como objetivo centralizar o que acontece no
domínio da aplicação, centrando sempre na lógica do negócio e no conhecimento do problema
para o qual o software foi criado.
Uma abordagem utilizada com este modelo é a separação em camadas, a fim de separar
os problemas. Geralmente, a camada base é definida através do padrão Domain Model, onde se
define o modelo de negócios. Já a segunda camada normalmente é a de serviços de domínio,
onde são fornecidos regras e comportamentos referentes ao modelo de domínio e a terceira

6
camada é o repositório de dados. De uma forma a exemplificar melhor essa divisão em camadas
que o modelo DDD traz é:

• Modelo de domínio: Normalmente definido através do padrão Domain Model, essa

camada é a base de todo o DDD. É aqui que precisamos definir corretamente nosso
modelo de negócios em termos de classes, do contrário teremos problemas posteriores
em nosso projeto.
• Serviços de domínio: Os serviços de domínio fornecem alguns métodos necessários à
aplicação, mas que não estão restritos à uma só entidade – como uma classe do modelo
de domínio é chamada. Em linhas gerais, contém regras e comportamentos referentes ao
Modelo de domínio.
• Repositórios de dados: Os repositórios de dados são definidos através de um padrão:
o padrão Repository. A ideia é que o Modelo de domínio esteja livre de qualquer definição
de infraestrutura de dados, fazendo com que ele siga os princípios POCO (Plain Old
Common-Runtime Object) e PI (Persistence Ignorance) – termos que são utilizados em
conjunto para indicar objetos que não possuem comportamentos (métodos) definidos
(entidades).

2.4 Acceptance Test-Driven Development (ATDD)

Por último, iremos falar do modelo ATDD ou Acceptance Test-Driven Development,

onde é uma prática de obtenção de requisitos de forma colaborativa aplicada por equipes ágeis,
onde exemplos concretos e testes automatizados são utilizados para especificar os requisitos,
tornando-os mais claros, com o objetivo de criar especificações executáveis. Eles são gerados
em sessões de criação do backlog do produto, com a participação da equipe, Product Owner,
além dos demais interessados.

O ATDD é muito similar ao TDD, diferenciando-se deste último pelo fato de termos
uma colaboração maior entre o desenvolvedor, analista de qualidade (tester) e negócio
(cliente/partes interessadas). Enquanto o teste unitário está intrinsicamente relacionado com o
código, de um ângulo do desenvolvedor (visão interna), o teste de aceitação está voltado ao
ponto de vista do usuário, uma visão externa ao sistema.
Neste modelo, os testes automatizados são utilizados para especificar os requisitos.

7
 O ciclo de implementação do ATDD gira em torno de basicamente 3 etapas na prática:
• Debater;
• Desenvolver;
• Revisar.

Enquanto Craig Larman e Bas Vodde, em seu artigo, consideram a aplicação do ATDD
como um fluxo de 3 etapas, ou seja: debater, desenvolver e revisar;
Hendrickson incluiu mais um passo: refinar. Portanto, exploraremos os 4 passos de
Hendrickson para ficar mais claro e detalhado como o processo funciona.

A principal diferença do ATDD, como oposto das outras abordagens ágeis, é seu foco
em fazer desenvolvedores, testers, analistas de negócios, product owners e outros stakeholders
colaborarem como uma unidade e criar um entendimento claro do que é necessário ser
implementado.

3.Testes Funcionais utilizando a semântica do BDD

3.1 Cenário: “Esqueci minha senha” na plataforma do Outlook (Restauração de senha)

Dado: Estou na tela de inserção de login/senha na tela principal do Outlook
Quando: Pressiono o botão de redefinição de senha
E: insiro meu email cadastrado
Então: A mensagem “email de redefinição de senha enviado com sucesso” deve
aparecer na tela
E: Através do meu email cadastrado criarei a senha com o link de redefinição enviado
anteriormente

8
3.2 Cenário: Compra no eCommerce
Dado: Que estou na tela de compras de determinado eCommerce
Quando: Insiro itens do meu interesse no carrinho de compras
E: Clicar no botão de comprar, após inserir todos os itens
Então: Na página de finalização de compras, inserir dados para pagamento
E: Dados de entrega (CEP) para o cálculo correto do frete
Então: Finalizar a compra, clicando no botão “finalizar”
E: Mensagem de “Compra realizada com sucesso” deverá ser apresentada

3.3 Cenário: Novo usuário no Twitter

Dado: Que estou na tela inicial do Twitter
Quando: Crio em “criar nova conta”
E: Inserir dados pessoais (Nome, email, telefone)
Então: Clicar em “Criar conta”
E: Através do email cadastrado, verificar a abertura da conta através de um link
enviado na abertura da nova conta no Twitter
Então: A nova conta já poderá ser utilizada

9
4. Conclusão

Levando em consideração as definições dos métodos acima, podemos dizer que o BDD
trabalha para definir como a demanda chegará ao time de desenvolvimento, integrando os
setores da empresa. Já o TDD busca a qualidade do código, buscando a cobertura total em testes
na aplicação. Portanto, se pode aplicar em conjunto os dois métodos, pois ambos buscam
melhorar o desenvolvimento de software.

Um desenvolvimento de software orientado a testes é uma excelente metodologia, pois

assim eventuais falhas já são identificadas logo no início e o desenvolvimento se torna mais
rápido e mais preciso, visando sempre um melhor código com menores possibilidades de
interrupção na usabilidade.

10
5. Referências Bibliográficas

https://www.devmedia.com.br/tdd-fundamentos-do-desenvolvimento-orientado-a-testes/28151
https://www.devmedia.com.br/desenvolvimento-orientado-por-comportamento-bdd/21127
https://www.devmedia.com.br/introducao-ao-ddd-em-net/32724
https://blog.locaweb.com.br/artigos/metodologias-ageis/diferenca-entre-bdd-tdd/
https://gaea.com.br/tdd-bdd-ddd/
https://www.agilealliance.org/glossary/bdd/#q=~(filters~(postType~(~'page~'post~'aa_book~'
aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(
~'bdd))~searchTerm~'~sort~false~sortDirection~'asc~page~1)
https://www.infoq.com/br/articles/atdd-passo-a-passo/
https://www.devmedia.com.br/introducao-ao-ddd-em-net/32724

11