ProjetosTítulo

Inserir ÁgeisAqui
Inserir
com Extreme
Título Aqui
Programming (XP)
Validação e Verificação em XP

Responsável pelo Conteúdo:

Prof. Me. Artur Ubaldo Marques Junior

Revisão Textual:
Prof.ª Dr.ª Selma Aparecida Cesarin
 Validação e Verificação em XP

Nesta unidade, trabalharemos os seguintes tópicos:

• Introdução;
• Metáfora;
• Design Simples;

Fonte: iStock/Getty Images

• Testes;
• Refatoração.

Objetivos
• Conhecer as boas práticas da XP.

Caro Aluno(a)!

Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o
último momento o acesso ao estudo, o que implicará o não aprofundamento no material
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.

Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns
dias e determinar como o seu “momento do estudo”.

No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões

de materiais complementares, elementos didáticos que ampliarão sua interpretação e
auxiliarão o pleno entendimento dos temas abordados.

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de
troca de ideias e aprendizagem.

Bons Estudos!
UNIDADE
Validação e Verificação em XP

Contextualização
Bem, você já deve conhecer a cena clássica em Empresas que desenvolvem software
em nosso país, não é mesmo?!

Empresa pequena, poucos funcionários, todo mundo fazendo tudo, muitos salvado-
res da pátria, clientes rosnando o dia todo e você atrasado com as entregas, cheio de
coisa para fazer, não sabe nem por onde começar e quando acha o fio da meada e se
concentra para desenvolver, vem logo um telefonema dizendo que o usuário precisou
fazer uma mudança num requisito, por necessidade do negócio.

E lá vamos nós, tudo de novo!

E assim o software vai atrasando, as entregas vão se distanciando da realidade e o

usuário descontente começa a desacreditar no Sistema que já sofre boicotes.

Então, você fica sabendo de Empresas e colegas que, ao contrário, obtém sucesso nas
entregas e têm um ar mais descarregado, menos estresse.

Você conversa com eles e a notícia é sempre a mesma: métodos ágeis, desenvolvi-
mento enxuto, scrum e XP.

Você tem contato com as 12 práticas e algo chama a sua atenção, porque parece
óbvio, mas no caos em que você está, fica meio sem sentido, porque simplesmente
não há tempo para isso... arrumar tempo para inventar metáforas, fazer um design
simples, realizar testes e fatoração constante...

Sim, mas eles conseguem, e o que é o melhor, fazem grandes aplicações de software
que funcionam e deixam o cliente feliz. Principalmente porque, pasmem, o cliente está tra-
balhando no mesmo ambiente que os desenvolvedores.

Blasfêmia!

Não! A mais pura verdade e ambos – desenvolvedores e clientes – vivem em harmonia.

Saiba que mais que nunca, XP é utilizado e desejado pelas grandes corporações
exatamente porque prega práticas possíveis e viáveis de tal forma que incrementam
a produtividade e os resultados.

Isso significa que você deve aprender essas técnicas e práticas agora!

Vamos lá?!

6
Introdução
XP usa, em vez de uma Arquitetura formal, uma simples história compartilhada de
como o Sistema funciona, ou seja, uma metáfora.

Essa história, geralmente, envolve um punhado de classes e padrões que moldam o fluxo
principal do Sistema que está sendo construído; porém, não são úteis em todos os projetos.

Estrutura em larga escala de software, por exemplo, em geral não é essencial. Mas,
não pense que se resolve com alguma técnica trivial ou padrão; muito pelo contrário;
teríamos de usar uma linguagem ubiquitous para promover entendimento comum do
domínio do negócio.

Porém, aqui se faz necessária uma distinção, conforme Ubiquitous Language (2012),
uma metáfora de Sistema diz respeito à Arquitetura da solução, enquanto uma Linguagem
Ubiquitous começa com o domínio do negócio.

Metáfora
A Metáfora do Sistema é uma das principais práticas do Processo de Desenvol-
vimento de software conhecido como XP. A prática da Metáfora do Sistema ainda
é mal compreendida e é a prática que as equipes de XP mais comumente escolhem
ignorar (BIDDLE, 2004).

Figura 1 – Metáforas para a primeira iteração relacionada aos requisitos funcionais

Fonte: Wikimedia Commons

7
7
UNIDADE
Validação e Verificação em XP

Aqui, podemos discriminar as fases dessa primeira iteração:

• O setor de requisitos funcionais envolve discussões sobre a aborda-
gem do problema ou oportunidade de negócios. Aqui devemos fazer
isso através de uma metáfora do sistema.

• Ou seja, uma comparação entre dois assuntos aparentemente não re-

lacionados. Eles são usados na linguagem para animar, encorajar a in-
terpretação e fornecer um veículo para a compreensão quando ou não
há termos diretos para um conceito ou outra explicação é incômoda.
Ao entender e experimentar uma coisa em termos de outra, podemos
fornecer um meio de explorar um conceito antes mesmo de termos
chegado a um acordo sobre o que estamos falando.

• Por exemplo, as palavras que usamos para negócios geralmente são

baseadas em uma metáfora de guerra: “aquisição hostil”, “perda de
terreno” e assim por diante, e essas, por sua vez, afetam a adminis-
tração dos negócios.

• Dentre as utilidades da Metáfora podemos citar também:

» Visão comum: permitir que todos concordem sobre como o siste-

ma funciona. A metáfora sugere a estrutura chave de como o pro-
blema e a solução são percebidos. Isso pode facilitar a compreensão
do que o sistema é e do que poderia ser.

» Vocabulário Compartilhado: a metáfora ajuda a sugerir um sis-

tema comum de nomes para objetos e as relações entre eles. Isso
pode se tornar um jargão no melhor sentido: um vocabulário po-
deroso e especializado para especialistas. Nomear algo ajuda a lhe
dar poder sobre isso.

» Generatividade: as analogias de uma metáfora podem sugerir no-

vas ideias sobre o sistema (problemas e soluções). Por exemplo, a
metáfora “Atendimento ao cliente é uma linha de montagem”. Isso
sugere a ideia de um problema ser entregue de grupo para grupo
a ser trabalhado, mas também levanta a questão: “O que acontece
quando o problema chega ao fim da linha – ele simplesmente cai?”
questões importantes que poderiam se esconder e apodrecer.

» Arquitetura: a metáfora molda o sistema, identificando objetos-cha-

ve e sugerindo aspectos de suas interfaces. Suporta os modelos de
objetos estáticos e dinâmicos do sistema.

» Outro benefício é a generalização. Podemos usar a metáfora para nos

movermos entre os desenvolvimentos: “Como o projeto de alface, mas
com mais de uma abordagem de água cinza” é uma sentença real usada
no desenvolvimento de um novo projeto. (WAKE, 2000)

Como identifico uma metáfora para o Sistema em desenvolvimento? Como eu sei que
é bom? O que faz uma boa metáfora? Editar-clarificação? Pode uma má metáfora fazer
mais mal do que bem? O que isso habilita? Como eu fico bom em encontrar metáforas?

Segundo Stakoverflow (2014), para usar metáforas eficazes:

• Tente criar um sistema que seja fácil de explicar usando analogias da
vida real. Seus sistemas são complexos, tente usar um design, onde o
relacionamento e as interações entre os subcomponentes são claros e
se assemelham a algo que as pessoas com bom senso já viram.

8
 • Use as analogias em todas as comunicações: código-fonte, planejamen-
to de reuniões, falar com os usuários ou abandonar Deus, escrevendo
a documentação. Se você achar que os conceitos que você usa não se
encaixam em alguma área, tente encontrar uma metáfora melhor.

Outra pratica utilizada em XP é a do design simples.

Design Simples
A Agile Alliance (2018) defende que uma equipe que adota a prática do “design sim-
ples” baseia sua estratégia de design de software nos seguintes princípios:
• Design é uma atividade contínua, que inclui refatoração e heurísticas,
como YAGNI;

• A qualidade do design é avaliada com base nas regras de simplicidade

de código;

• Todos os elementos de design, como “padrões de projeto”, arquitetu-

ras baseadas em plug-in, etc., são vistos como tendo custos e benefí-
cios, e os custos de design devem ser justificados;

• As decisões de projeto devem ser adiadas até o “último momento res-

ponsável”, de modo a coletar o máximo de informações possível sobre
os benefícios da opção escolhida antes de incorrer em seus custos.

É enganoso invocar a prática de design simples para justificar decisões que têm a ver
com os requisitos de um cliente ou proprietário do produto, ou considerações de usa-
bilidade. Essas práticas podem ser muito inconsistentes se o grupo de desenvolvedores
for muito grande ou distribuído em vários locais.

Para utilizar essas práticas, a Agile Alliance ainda sugere que as equipes:
• Mantenham um backlog de tarefas específicas de design:

» Falhas de design que exigem uma correção explícita por meio

de refatoração;

» Oportunidades para simplificar o código existente;

» Decisões de design em potencial adiadas até que mais informa-

ções cheguem;

» Esse backlog não permanece estagnado, ou uma simples lista de re-

clamações nunca abordadas; a equipe reserva tempo suficiente para
lidar regularmente com os problemas (ou decide morar com eles);

» A equipe usa regularmente uma ou mais das práticas auxiliares que

oferecem oportunidades explícitas para discutir o design;

» Qualquer impressão de que mudanças funcionais relativamente sim-

ples exijam quantidades excessivas de esforço para implementar é
um “sinal de alerta” de que a prática pode não ser efetivamente
usada. (AGILE ALLIANCE, 2018)

9
9
UNIDADE
Validação e Verificação em XP

Tabela 1 – Níveis de Habilidades de colaboração individual para o uso do código simples

Níveis de Habilidade para Aplicar a Técnica
Capaz de identificar elementos de design que não são benéficos o suficiente para justificar sua
Principiante
complexidade e refatoram para simplificar a estrutura do código.
Pode adiar uma decisão de projeto que pode ser exigida por uma exigência futura, e identificar as
Intermediário
condições sob as quais a decisão deve ser arbitrada.
Capaz de identificar o momento certo para introduzir uma decisão de projeto de longo alcance,
Avançado
como uma arquitetura baseada em plugins em um aplicativo de desktop.
Fonte: https://goo.gl/sDpTgt

Mais do que níveis de habilidade, em XP, as práticas consistentemente empregadas

têm papel muito importante, de tal forma que, a definição de simplicidade em XP pode
ser simplificada para os 4 seguintes termos:
• Executar todos os testes;
• Não conter código duplicado;
• Afirmar a intenção do programador para todo o código claramente;
• Conter o menor número possível de classes e métodos.

Portanto, tire da sua cabeça que a atividade de design é feita uma única vez, em uma
fase obscura de algum ciclo de vida de projeto de software criado por algum ninja.

Afinal, ver o design como um evento único é simplista e restrito, ele é um processo
contínuo que acontece nos níveis conceitual e físico. Isso faz todo o sentido quando você
considera que a mudança é um dado e nós nunca temos certeza do que está por vir.

Shore (2010) fala sobre a necessidade da autodocumentação do código sendo

gerado e diz:
A simplicidade está nos olhos de quem vê. Não importa muito se você
acha que o design é simples; se o resto de sua equipe ou futuros man-
tenedores de seu software acharem isso muito complicado, então é.

Para evitar esse problema, use expressões idiomáticas e padrões co-

muns para seu idioma e equipe. Não há problema em apresentar no-
vas ideias também, mas passe-as por outros membros da equipe pri-
meiro. Certifique-se de usar nomes que reflitam claramente a intenção
de suas variáveis, métodos, classes e outras entidades.

Quando você cria designs simples, evita adicionar suporte a recur-

sos diferentes daqueles em que está trabalhando na iteração atual.
Você termina o trabalho mais rapidamente como resultado. Quando
você usa um design simples, seu design suporta alterações arbitrá-
rias facilmente. Embora novos recursos possam exigir muitos códigos
novos, as alterações no código existente são localizadas e simples.

O design simples requer melhoria contínua por meio de refatoração e

design e arquitetura incrementais. Sem isso, seu design não consegui-
rá evoluir com seus requisitos.

Não use design simples como uma desculpa para um design ruim. Simpli-
cidade requer um pensamento cuidadoso. Como diz a citação de Einstein

10
 no início desta seção, é muito mais fácil criar projetos complexos do que
os simples. Não finja que “simples” significa “mais rápido” ou “mais fácil”.

A programação em pares e a propriedade coletiva de código, embora

não sejam estritamente necessários para um design simples, ajudarão
sua equipe a dedicar a capacidade cerebral necessária para criar designs
realmente simples. (SHORE, 2010)

Testes
Sabemos que XP reinventou a forma de escrever código, principalmente, no que-
sito de aplicação de testes.

Em vez de testar após o desenvolvimento, os desenvolvedores escrevem o teste antes

da codificação. Nós nos referimos aos testes de unidade que trabalham sobre cada mé-
todo e cada coisa que poderia quebrar no software.

Baird (2002) escreve que “Quando eles escrevem todos os testes para esse compo-
nente, eles escrevem apenas código suficiente para passar no teste. Escrever testes nos
fornece um conjunto completo para o nosso sistema e escrevemos a coisa mais simples
que poderia funcionar”.

Add a test

[Pass]
Run the test

[Fail]

Make a little
change

[Development
continues]

[Fail]
Run the test

[Development
stops]

Figura 2 – Processo de teste usando TDD em XP

Fonte: https://goo.gl/sHx28x

11
11
UNIDADE
Validação e Verificação em XP

Fowler (2014), um dos apoiadores e desenvolvedores do XP, junto com Kent Beck
(criador do XP), que também fez o TDD – Test Driven Development, define o teste
de unidade:
Apesar das variações, existem alguns elementos comuns. Em primeiro
lugar, há uma noção de que os testes de unidade são de baixo nível,
concentrando-se em uma pequena parte do sistema de software. Em
segundo lugar, os testes unitários geralmente são escritos hoje em dia
pelos próprios programadores, usando suas ferramentas regulares – a
única diferença é o uso de algum tipo de estrutura de testes unitários.
Em terceiro lugar, espera-se que os testes unitários sejam significativa-
mente mais rápidos do que outros tipos de testes.

Portanto, há alguns elementos comuns, mas também existem dife-

renças. Uma diferença é o que as pessoas consideram uma unidade.
O design orientado a objetos tende a tratar uma classe já que as
abordagens unitária, processual ou funcional podem considerar uma
única função como uma unidade. Mas, na verdade, é uma questão
situacional – a equipe decide o que faz sentido ser uma unidade para
fins de compreensão do sistema e de seus testes. Embora se comece
com a noção de que a unidade é uma classe, muitas vezes pegamos
um monte de classes estreitamente relacionadas e podemos as tratar
como uma única unidade. Raramente podemos pegar um subconjun-
to de métodos em uma classe como uma unidade. No entanto, o time
deve definir o que realmente não importa.

Sociable Tests Solitary Tests

Often the tested unit relies Some unit testers prefer to

on other units to fulfill isolate the tested unit
its behavior

Figura 3 – Forma de realizar testes Solitários ou Sociáveis em XP

Fonte: Adaptado de Fowler, 2014

Imagine que você está testando o método de preço de uma classe de pedidos. O método
de preço precisa invocar algumas funções nas classes de produto e cliente. Se você quiser
que seus testes unitários sejam solitários, não deseja usar o produto real ou classes de
clientes aqui, porque uma falha na classe do cliente faria com que os testes da classe de
pedido falhassem. Em vez disso, você usa Test Doubles para os colaboradores.

Por fim, lembre-se que a maioria das linguagens possui frameworks de testes unitários.
Você deve procurar um que se adapte ao jeito da sua equipe desenvolver as coisas, os testes,
geralmente, são executados periodicamente, normalmente, após cada alteração no código-
-fonte. Quanto mais vezes, melhor, porque pegaremos os problemas mais cedo.

Bom, você ainda está em dúvida do que é um teste unitário.

Vamos resumir isso de forma mais clara.

O teste de unidade da unidade simplesmente verifica se as unidades individuais de

código (principalmente funções) funcionam conforme o esperado. Normalmente, escre-
vemos os casos de teste, mas alguns podem ser gerados automaticamente.

12
 Daí a necessidade de você escolher a ferramenta mais adequada para realizar a au-
tomação disso.

Stackoverflow (2018) dá um exemplo clássico de uma função para teste:

Quadro 1 – Stackoverflow, 2018

Imagine uma função muito simples, que você gostaria de testar:
intCombineNumbers(int a, int b) {
returna+b;
}
O código de teste unitário seria algo como isto:
void TestCombineNumbers() {
Assert.IsEqual(CombineNumbers(5, 10), 15); // Assert is an object that is
part of your test framework
Assert.IsEqual(CombineNumbers(1000, -100), 900);
}
Quando você executar os testes, será informado de que esses testes foram aprovados. Agora que você construiu e
executou os testes, sabe que essa função ou unidade específica funcionará conforme o esperado.
Agora, imagine outro desenvolvedor aparecer e mudar a CombineNumbers()função para desempenho, ou algum
outro motivo:
intCombineNumbers(int a, int b) {
return a * b;
}
Quando o desenvolvedor executa os testes que você criou para essa função muito simples, eles verá que o primeiro
Assert falha e agora sabe que a compilação está quebrada.
Fonte: https://goo.gl/56kBTX

Vamos comentar, também, os outros tipos de testes envolvidos com XP, do mais bási-
co, que vimos até aqui, que é o Teste Unitário, até o desejável Teste de Aceitação, normal-
mente, feito pelo usuário.

Do mais baixo nível para o mais alto nível, aqui vai:

Tabela 2 – Tipos de testes possíveis em XP

O objetivo é validar que cada unidade do software tenha o desempenho planejado.
Teste de Unidade Uma unidade é a menor parte testável de qualquer software. Geralmente tem uma ou
algumas entradas e geralmente uma única saída. É mandatório em XP.
É um nível de teste de software onde as unidades individuais são combinadas e testadas
como um grupo. A finalidade deste nível de teste é expor falhas na interação entre unidades
Teste de Integração
integradas. São realizados para expor defeitos nas interfaces e nas interações entre
componentes ou sistemas integrados. Teste não obrigatório.
É um nível de teste de software em que um software completo e integrado é testado.
O objetivo deste teste é avaliar a conformidade do sistema com os requisitos especifica-
Teste de Sistema
dos. É o terceiro nível de teste de software realizado após o Teste de Integração e antes
do Teste de Aceitação. É um teste não obrigatório.
São testes formais com relação às necessidades do usuário, requisitos e processos de negócios
conduzidos para determinar se um sistema satisfaz ou não os critérios de aceitação e para
Teste de Aceitação permitir que o usuário, clientes ou outra entidade autorizada determine se aceita ou não o
sistema. É considerado um teste necessário e que suporta os de unidade, pois são realizados
pelos usuários.
Fonte: https://goo.gl/hPd4RB

13
13
UNIDADE
Validação e Verificação em XP

Você poderá utilizar vários frameworks para auxiliar na criação de testes de unida-
de, por exemplo: jUnit, xUnit, nUnit. Essas estruturas fornecem uma maneira formali-
zada de criar testes.

Refatoração
Teles (2006) escreve que a estrutura de qualquer Sistema tende a se degradar ao lon-
go do tempo, à medida que novas funcionalidades são inseridas, alterações são feitas,
erros são corrigidos e mais código é introduzido.

A refatoração é uma prática para que todas essas alterações venham a transformar o
Sistema em algo lento, obsoleto e ineficiente.

Maniuk (2006) vem ao encontro dessa prescrição, e define que:

A refatoração é uma prática de desenvolvimento de software que
permite melhorar o código sem alterar ou interromper sua funcio-
nalidade. O código deve ser o mais simples possível para encontrar
todos os bugs e facilitar a mudança de algo no processo de desem-
penho do projeto.

A refatoração é especialmente necessária na programação extrema por exigir um

forte envolvimento do cliente durante o projeto.

Os objetivos da refatoração são:

• Simplificação do código inicial;
• Integrar a refatoração na rotina diária dos desenvolvedores;
• A refatoração deve ser constante em todas as fases de produção de código e veri-
ficação e validação.

Refatorar envolve um processo ou ao menos uma rotina. Veja umas dicas sobre
como montar uma rotina:
• Encontre um teste de trabalho adequado para uma parte do código que você de-
seja refatorar;
• Proceda com a refatoração;
• Realize o teste de unidade da unidade que foi refatorada;
• Proceda com a repetição dos itens anteriores para todas as outras unidades
desenvolvidas.

XP pede que a refatoração seja realizada impiedosamente; portanto, se encontrar dois

métodos parecidos, refatore o código para combiná-los. Quando se encontram dois obje-
tos com funcionalidade comuns, refatore para que haja apenas um.

14
 Figura 4 – Exemplo de framework de trabalho XP contendo refatoração
Fonte: https://goo.gl/wm9VS7

Hilliges (2018) assim explica:

• Aberto: todas as histórias de usuários são colocadas no início do sprint;
• Em andamento: um desenvolvedor começa a trabalhar numa história de usuário;
• Teste de unidade automatizada: uma história de usuário está pronta para testes
de unidade automatizados;
• Teste de aceitação: se o teste da unidade automatizada passar, ele entrará no teste
de aceitação, que é idealmente tratado pelo cliente;
• Refatoração necessária: se qualquer uma das etapas de teste falhar, a história do
usuário precisará ser refatorada antes de ser testada novamente;
• Completo: em que a história do usuário ocorre quando todos os testes são aprovados.

15
15
UNIDADE
Validação e Verificação em XP

Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Vídeos
Refactoring Strategies: a walkthrough experiment
SATO, D. Refactoring Strategies: a walkthrough experiment. 2011.
https://goo.gl/UvQsbv
Universidade XTI - JAVA - 114 - Teste Unitário com JUnit
JAVA & CIA. Teste Unitário com JUnit. 2014.
https://youtu.be/MF2_IbbG2gA
10 Mandamentos do Teste Automatizado
GUERRA, E. 10 Mandamentos do Teste Automatizado. 2014.
https://youtu.be/OinhnbZWo3A

Leitura
Adoção da Metodologia Extreme Programming para Construção de Software
DIAS, T. M. R.; OLIVEIRA, J. L. L. Adoção da Metodologia Extreme Programming
para Construção de Software. 2009.
https://goo.gl/KrwHRU

16
Referências
FOWLER, M. UnitTest. 2014. Disponível em: <https://martinfowler.com/bliki/Unit-
Test.html>. Acesso em: 25 maio, 2018.

KHALED, R. et al. System Metaphor in “Extreme Programming”: A Semiotic

Approach. 2004. Disponível em: <https://www.researchgate.net/publication/22887289
0_System_Metaphor_in_Extreme_Programming_A_Semiotic_Approach>. Acesso em: 23
maio, 2018.

MANIUK, I. Refactoring in Extreme Programming. 2016. Disponível em: <https://

hygger.io/blog/refactoring-in-extreme-programming/>. Acesso em: 25 maio, 2018.

SHORE, J. The Art of Agile. 2010. Disponível em: <http://www.jamesshore.com/

Agile-Book/simple_design.html>. Acesso em: 24 maio, 2018.

STACKOVERFLOW. What is a metaphor in the context of XP? 2014. Disponí-

vel em: <https://stackoverflow.com/questions/211557/what-is-a-metaphor-in-the-con
text-of-xp>. Acesso em: 22 maio, 2018.

TELES, V. M. Refatoração. 2006. Disponível em: <http://www.desenvolvimentoagil.

com.br/xp/praticas/refatoracao>. Acesso em: 25 maio, 2018.

UBIQUITOUS Language. 2012. Disponível em: <http://wiki.c2.com/?UbiquitousLangua

ge>. Acesso em: 25 maio, 2018.

WAKE, W. System Metaphor. 2000. Disponível em: <http://www.xp123.com/

xplor/xp0004/index.shtml>. Acesso em: 24 maio, 2018.

17
17