Fases de codificação e testes

Codificação

Após a fase de projeto/design do produto, a equipe de desenvolvimento escreverá os testes unitários. A prática de escrever testes antes da codificação pode parecer complexa inicialmente, mas os testes unitários desempenham um papel crucial na manutenção da qualidade do projeto. Essa abordagem também pode aprimorar a eficiência do projeto, pois direciona o desenvolvedor para a implementação precisa do que é necessário.

Terças e quintas de TI. Conteúdo prático e artigos especializados para acelerar seu conhecimento. Acesse agora!

Na etapa de implementação, é importante destacar que a programação no XP é realizada em pares. Essa técnica envolve dois programadores compartilhando uma única máquina para desenvolver o código, onde um programa e o outro observa em busca de identificar erros para correção imediata.

É recomendável integrar continuamente novas funcionalidades com a versão atual do sistema, evitando possíveis conflitos e erros no código. A integração contínua proporciona um entendimento preciso do status real da codificação e possibilita um feedback mais rápido.

Testes

Os testes de unidade, escritos durante a fase de codificação, e os testes de aceitação, elaborados pelo cliente, são aplicados. A automação dos testes é recomendada para facilitar a execução.

Os testes de regressão são executados constantemente no XP, especialmente após a correção de defeitos ou a adição de novas funcionalidades, visando garantir que nenhum defeito seja adicionado ao sistema ao longo da evolução. Dado que várias integrações são realizadas frequentemente, os testes de regressão desempenham um papel crucial.

Os testes de unidade podem ser agrupados em conjuntos, enquanto os testes de integração e validação do sistema podem ocorrer diariamente, dependendo do ritmo da equipe.

É fundamental compreender que os testes têm o propósito de prevenir falhas futuras, evitando desperdício de recursos e tempo. Descobrir falhas no início do processo é mais eficiente do que lidar com custos mais elevados durante sua descoberta ou ajuste futuro.

Na prática diária, nem todas as organizações que adotam o XP utilizam todas as práticas. Cada organização e equipe têm a liberdade de escolher aquelas que consideram mais úteis, eficientes e viáveis para sua realidade. Logo, o XP é adaptável e não descreve uma metodologia passo a passo.

A equipe tem a opção de criar um protótipo ou realizar um desenvolvimento de teste para compreender tanto o problema quanto a solução. Na linguagem XP, essa abordagem é denominada “spike” – um incremento no qual nenhuma programação real é executada. Além disso, podem ocorrer spikes relacionados ao design da arquitetura do sistema ou para desenvolver a documentação do sistema.

Com intuito de melhorar nosso conhecimento, colocamos uma tabela com comparando o Scrum e o XP.

Aspecto	Scrum	Extreme Programming (XP)
Origem	Desenvolvido por Ken Schwaber e Jeff Sutherland nos anos 1990. Ficou popular nos anos 2000	Desenvolvido por Kent Beck no final dos anos 1990.
Objetivo	Fornecer um framework para o desenvolvimento de produtos complexos.	Melhorar a qualidade do software e a capacidade de resposta às mudanças.
Papéis	Scrum Master, Product Owner, Development Team.	Coach, Customer, Programmer, Tracker, Tester. (as bancas podem utilizar estes termos)
Artefatos	Product Backlog, Sprint Backlog, Increment.	User Stories, Task Cards, Tests, Code, Release Plan.
Eventos	Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.	Planning Game, Small Releases, Metáforas, Design Simples, Testes, Refatoração, Programação em Par, Desenvolvimento Dirigido por Testes (TDD), Integração Contínua
Sprints/Iterações	Sprints de 2 a 4 semanas.	Iterações curtas de 1 a 2 semanas.
Planejamento	Sprint Planning para definir o trabalho a ser feito na Sprint.	Planning Game para definir o trabalho a ser feito na iteração.
Entrega	Entregas incrementais ao final de cada Sprint.	Entregas frequentes e iterativas com foco em releases pequenos.
Revisão e Adaptação	Revisão da Sprint, Retrospectiva da Sprint.	Feedback contínuo, ajustes frequentes nas práticas.
Prioridade	Priorização baseada no valor do negócio, feita pelo Product Owner.	Priorização feita pelo Cliente baseado no valor e necessidades.
Qualidade	Foco em entregas de alta qualidade e inspeção contínua.	Foco intenso em testes automatizados e práticas de codificação para garantir alta qualidade.
Comunicação	Reuniões diárias (Daily Scrum) para comunicação rápida e frequente.	Comunicação constante entre todos os membros da equipe, especialmente através da programação em par.
Documentação	Documentação é mínima e apenas o necessário para a entrega do produto.	Código é a documentação principal, complementada por testes.
Melhoria Contínua	Retrospectiva da Sprint para identificar e implementar melhorias.	Refatoração contínua e integração de feedback para melhorias contínuas.

CESPE / CEBRASPE – 2024 Engenharia de Software

Teste de Software CAU-BR Analista de Tecnologia da Informação Julgue o próximo item, relativo a testes de software.

Um conceito-chave na atividade de codificação na XP, ainda que incompatível com a execução de testes unitários, é a programação em pares, em que duas pessoas trabalham juntas em uma mesma estação de trabalho para criar código.

COMENTÁRIO

O que torna a questão incorreta é dizer que a codificação em pares é “incompatível com a execução de testes unitários”.

A programação em pares pode ser extremamente eficiente na escrita de testes unitários de qualidade. O par pode colaborar na identificação de cenários de teste e na escrita de testes mais eficazes, além de promover a melhoria contínua.

Gabarito está ERRADO.

CESPE / CEBRASPE – 2022 Engenharia de Software XP (eXtreme Programming) BANRISUL Analista – Desenvolvimento de Sistemas

Em relação a metodologias ágeis de desenvolvimento de software, julgue o seguinte item.

Um aspecto central na XP é o fato de que a elaboração do projeto ocorre tanto antes quanto depois de se ter iniciado a codificação.

COMENTÁRIO

Na XP, o desenvolvimento de software segue um modelo iterativo e incremental, onde as atividades de planejamento, design, codificação e testes ocorrem de forma constante durante todo o projeto. Diferentemente de metodologias tradicionais, em que o design é finalizado antes de iniciar a codificação, a XP destaca a importância de uma adaptação contínua conforme o projeto evolui.

Gabarito está CORRETO.

CESPE – 2017 – TRE-BA – Técnico Judiciário – Programação de Sistemas

Considerando uma situação hipotética com o uso da XP (eXtreme Programming) concomitante com Scrum em um projeto de desenvolvimento de software em uma organização, julgue os seguintes itens.

I É viável a utilização do TDD (Test Driven Development) na fase de sprint, de modo que se escreva o teste automático antes da codificação.

II O princípio da integração contínua da XP deve ser utilizado especificamente na retrospectiva da sprint com vistas a integrar a equipe scrum.

III Integrantes da equipe scrum podem realizar a programação do código em pares, o que proporciona, entre outras vantagens, o nivelamento de conhecimento da equipe.

IV O conceito de requisito “pronto” continuaria válido, contudo, inviabilizaria o refactoring, pois é proibitivo inserir o mesmo item (requisito) em várias sprints.

Estão certos apenas os itens

Alternativas

I e II.
I e III.
II e IV.
I, III e IV.
II, III e IV.

Comentário

Os dois modelos ágeis para desenvolvimento podem compartilhar inúmeras características, não tornando inviável nem invalidando seus respectivos usos.

I – Como uma prática do XP, os testes devem ser escritos antes da codificação propriamente dita. Eles são executados a partir de testes unitários do código produzido e são preparados com base nos critérios de aceitação definidos previamente pelo cliente.

II – Não faz sentido afirmar que a integração contínua deve ser aplicada somente na retrospectiva da Sprint. Essa prática é contínua. O código das funcionalidades implementadas pode ser integrado várias vezes ao dia.

III – Embora seja uma prática do XP, isso não significa que não possa ser adotada por outros métodos e modelos, como o Scrum.

O código é produzido por um par de programadores que têm funções distintas, trabalhando lado a lado em um mesmo computador.

IV – Considerada uma das práticas do XP, a refatoração consiste em aplicar uma série de passos para aprimorar o design do código existente, tornando-o mais simples e melhor estruturado, sem alterar sua funcionalidade. Deve ser aplicada constantemente no projeto e pode ser realizada por qualquer um dos desenvolvedores, pois o código é de propriedade coletiva.

Gabarito é a letra B.