Esta disciplina compreende a implementac¸˜ao e os testes da aplicac¸˜ao. Pr´aticas como Reuni˜oes Di´arias, Programac¸˜ao Pareada, Integrac¸˜ao Cont´ınua e Padr˜oes de C´odigo s˜ao ´uteis nesta disci- plina, assim como qualquer outra pr´atica que ajude o time de desenvolvimento a implementar a aplicac¸˜ao da melhor forma poss´ıvel.
Tendo como base os artefatos da disciplina anterior, o time de desenvolvimento deve criar a infraestrutura necess´aria para dar suporte a iterac¸˜ao em cada Sprint. Provavelmente, a primeira iterac¸˜ao ter´a mais atividade de suporte, como criar um banco de dados baseado no Diagrama de Classe ou no Modelo de Banco de Dados. ´E recomendado utilizar esse momento para gerar todos os poss´ıveis c´odigos autom´aticos (como o CRUD). S´o ent˜ao escrever e testar o c´odigo referente as regras de neg´ocio.
O time de desenvolvimento deve ent˜ao converter as Hist´orias do Usu´ario da lista de ati- vidades da iterac¸˜ao do Sprint (Sprint Backlog) para obter a estrutura dos testes funcionais na linguagem alvo da implementac¸˜ao, no caso o C#. Essa convers˜ao ´e realizada pelo conversor Story2CSharp. A Figura 5.8 mostra o resultado dessa convers˜ao.
Conforme mostra a Figura 5.8, foi gerada uma classe de testes com o nome indicando o uso da DLL Story2CSharp e cada hist´oria se transforma em um m´etodo test´avel. ´E importante notar que apesar de convertida para C#, a hist´oria ´e leg´ıvel, visando a manter um n´ıvel de abstrac¸˜ao pr´oximo ao oferecido pela LET.
Na sequˆencia ´e criada uma vari´avel Story, que conter´a as informac¸˜oes da Hist´oria do Usu´ario. O conte´udo de cada cen´ario ´e dividido em m´etodos que s˜ao declarados externamente ao m´etodo test´avel. O nome de cada m´etodo ´e precedido de um underscore ( ) onde os seus respectivos atributos se encaixam no nome, para facilitar sua leitura. Esses m´etodos s˜ao criados com o objetivo de lanc¸ar uma excec¸˜ao para indicar que ainda n˜ao foram implementados. No final do m´etodo test´avel, uma func¸˜ao interna ´e chamada para executar a hist´oria.
Uma vez que os testes funcionais foram gerados, o time de desenvolvimento pode execut´a- los e analisar seus resultados. Como o c´odigo acabou de ser gerado, o resultado mais prov´avel ´e que o teste funcional seja “inconclusivo”, uma vez que os m´etodos de cada cen´ario s˜ao apenas estruturas, que lanc¸am excec¸˜oes avisando que cada m´etodo est´a pendente, e as regras de neg´ocio ainda n˜ao foram implementadas. A Figura 5.9 mostra esse resultado.
Figura 5.9: Resultado mostrando que o teste funcional foi inconclusivo, devido aos m´etodos pen- dentes.
Prosseguindo, o time de desenvolvimento escreve o c´odigo para testar a l´ogica de neg´ocio da Hist´oria do Usu´ario, para que seus passos acusem falhas. Para corrigir as falhas, implementa- se a l´ogica de neg´ocio, para que os passos sejam aprovados nos testes. A Figura 5.10 mostra o caso de falha do teste funcional e a Figura 5.11 mostra o teste funcional sendo aprovado.
Figura 5.10: Resultado mostrando que o teste falhou.
Figura 5.11: Resultado mostrando que o teste foi aprovado.
O uso desta t´ecnica n˜ao impede a utilizac¸˜ao de testes unit´arios. Ao contr´ario, a utilizac¸˜ao destes testes ajuda a complementar a avaliac¸˜ao da Hist´oria do Usu´ario. Formas de integrar os testes unit´arios com os testes funcionais pode ser encontrada nos livros The RSpec Book (CHELIMSKY et al., 2010) e The Cucumber Book (WYNNE; HELLESøY, 2012).
Uma vez que os Mock-ups s˜ao artefatos do processo, o projeto final das p´aginas da aplicac¸˜ao correspondentes `as regras de neg´ocio das Hist´orias do Usu´ario seguem o que esses Mock-ups definiram com o usu´ario. A Figura 5.12 mostra a vers˜ao entregue ao usu´ario dos Mock-ups Sign Up e Getting Started, ambos utilizados como exemplo da aplicac¸˜ao MySocial.
(a) P´agina Sign Up.
(b) P´agina Getting Started.
Figura 5.12: P´aginas criadas seguindo os testes funcionais das Hist´orias do Usu´ario da iterac¸˜ao e baseadas nos Mock-ups da Figura 5.4.
O resultado final ´e a l´ogica de neg´ocio implementada, funcionalmente testada, conforme os requisitos especificados nas Hist´orias do Usu´ario. Essas hist´orias s˜ao tratadas como testes de aceitac¸˜ao que simulam o comportamento esperado pelo usu´ario. ´E importante perceber que corrigindo os erros que aparecem durante esses testes, o time de desenvolvimento pode criar uma aplicac¸˜ao mais pr´oxima das necessidades do usu´ario, particularmente no que se refere ao processamento das regras de neg´ocio.
Esse processo ´e repetido iterativamente, atrav´es de todos os crit´erios de aceitac¸˜ao de cada cen´ario presente nas Hist´orias do Usu´ario. O c´odigo necess´ario ´e implementado at´e que todas as Hist´orias do Usu´ario da iterac¸˜ao n˜ao apresentem mais erros. No final desta ´ultima disciplina, a iterac¸˜ao do Sprint termina e um prot´otipo totalmente funcional est´a pronto.
5.3
Fases do Processo
O processo de desenvolvimento ´e realizado em ciclos, ao longo de quatro fases conse- cutivas. Cada fase ´e composta por seus objetivos, suas atividades e seus artefatos gerados e refinados. A principal disciplina de cada fase tamb´em ´e destacada. Para cada Sprint essas fases se repetem produzindo vers˜oes cada vez mais completas e refinadas da aplicac¸˜ao.