Teste de Software

TESTE DE CAIXA PRETA - TESTE FUNCIONAL

Simula a usabilidade de um usuário dentro do software, testando se

determinada funcionalidade está atendendo aos requisitos estabelecidos
anteriormente com o cliente. Podem ocorrer testes de regressão(verifica se uma
parte da aplicação que já funcionava, não deixou de funcionar), de funcionalidade,
testes UI(testes de tela, para garantir que ela possui o comportamento esperado
independente do dispositivo).

TESTE DE CAIXA BRANCA - TESTE ESTRUTURAL

Ligado ao código-fonte da aplicação, testes de unidade, testes de integração,

teste de carga(para detectar gargalos).

**Baixo nível - mais ligados aos testes de caixa branca.

**Alto nível - mais ligados aos testes de caixa preta.
O TESTE ÁGIL
REGRA 10 de MYERS

Esta regra estabelece que o custo de correção de uma falha é mais custoso
quanto mais tarde o defeito é encontrado. Corrigir um defeito encontrado durante a
produção é muito mais caro de se resolver do que quando é encontrado ainda na
fase de desenvolvimento.

TESTES MAIS COMUNS

● Teste de unidade
○ aquele que teste uma única unidade do sistema, de maneira isolada,
simulando as dependências da unidade em questão. em linguagens
orientadas a objeto, é comum que uma unidade seja uma classe, ou
seja, tal classe é testada de maneira isolada sem interações com
outras classes.
● Teste de integração
○ testa a integração entre duas ou mais partes da aplicação, verificando
a interação entre classes e demais áreas do software(camadas, banco
de dados, serviço externo etc). Estes testes garantem que as unidades
da aplicação estão se integrando de acordo com o esperado.
● Testes automatizados
○ funciona como um teste de caixa preta, onde o sistema é testado de
ponta a ponta através das operações executadas no sistema. A
automatização garante que toda a operação será executada da mesma
maneira que um usuário utilizaria a aplicação.Pode ser considerado um
teste de aceitação e de regressão, uma vez que, garante a
funcionalidade ponta a ponta (validando características do negócio e
funcionalidades) e que não surgiram novos defeitos em componentes
que estavam funcionando em versões anteriores.
● Testes de carga
○ também conhecido como load test tem como objetivo testar a
capacidade da aplicação, até o seu limite, de forma que a aplicação
não consiga mais responder, podendo ser considerado um test de
stress. Testa a performance do código em busca de possíveis gargalos,
o comportamento da aplicação com um determinado número de
usuários simultâneos e garantir que o mesmo vá atender a demanda.
Possibilita testar um possível balanceamento de carga no servidor ou
até mesmo escala elástica na nuvem. Importante para aplicações web
ou para aplicações onde é esperado um grande volume de requisições.
 TESTE DE UNIDADE

Frameworks para teste de Unidade

● MSTest
● NUnit
● XUnit
AAA
O teste de unidade pode ser separado em 3 partes:
● Arrange (arranjar)
○ a manipulação do objeto que vai ser chamado (act) (organiza/prepara,
é o código necessário para gerar um objeto)
● Act (ação)
○ é o que chama o método (geralmente é apenas uma linha de código)
● Assert (asserção)
○ válida se os resultados gerados pela chamada do método conferem
com a intenção do teste

NOMENCLATURA DE TESTES DE UNIDADE

ObjetoEmTeste_ComportamentoDoMetodoEmTeste_ComportamentoEsperado
ex - Pedido_AdicionarPedidoItem_DeveIncrementarUnidadesSeItemJaExistente
ex - Estoque_RetirarItem_DeveEnviarEmailSeAbaixoDe10Unidades

MetodoEmTeste_EstadoEmTeste_ComportamentoEsperado
ex - AdicionarPedidoItem_ItemExistenteCarrinho_DeveIncrementarUnidadesDoItem
ex - RetirarItemEstoque_EstoqueAbaixoDe10Unidades_DeveEnviarEmailDeAviso

MOCK

Também conhecido como objetos mock, são objetos que simulam o

comportamento de objetos reais de forma controlada. Ou seja, são objetos falsos
que simulam o comportamento de uma classe/objeto real para que se possa focar o
teste na unidade a ser testada, podendo este ser criado por um framework.
ASSERT - Strings
● Assert.Equal
○ Realiza comparação, inclusive strings e não apenas numbers
● Assert.Contais
○ Verifica se contém um conjunto de caracteres
● Assert.StartsWith
○ Verifica o começo da string
● Assert.EndsWith
○ Verifica o fim da string
● Assert.Matches
○ Válida a partir uma expressão regular

ASSERT - Number
● Assert.Equal
○ Realiza comparação, inclusive strings e não apenas numbers
● Assert.NotEqual
○ Compara para verificar se os números não são iguais. Leva a precisão
em conta (expected: x, actual: xx, precision: x)
● Assert.InRange
○ Verifica se a expressão está dentro de uma determinada faixa de valor
(actual: xxx, low: xxx, high: xxx)
● Assert.NotInRange
○ Verifica se a expressão não está dentro de uma determinada faixa de
valor (actual: xxx, low: xxx, high: xxx)

ASSERT - Boolean
● Assert.False
○ Testa se a expressão é falsa
● AssertTrue
○ Testa se a expressão é verdadeira
● AssertNull
○ Testa se a expressão é nula (também existe o AssertNotNull que
verifica se a expressão não é nula)
Assert - Collection
● AssertAll
○ Verifica uma situação para todos os itens de uma collection
● AssertContains
○ Verifica se o valor esperado se encontra na collection
● AssertDoesNotContains
○ Verifica se o valor esperado não se encontra na collection

FIXTURE
A fixture é um conjunto de configurações que são compartilhadas entre vários
testes de uma mesma classe.

DUBLÊ DE TESTE
É um objeto usado para simular uma dependência do código sendo testado. O
dublê é criado com o propósito de imitar um comportamento sem causar efeitos
colaterais, o que auxilia no isolamento dos testes sendo feitos.

SUÍTE DE TESTE
É o diretório ou caminho onde um determinado agrupamento de classes de
teste se localizam.

ORDENAÇÃO DE TESTE
Existe uma grande discussão em torno da ordenação de testes, pois como se
trata de um teste unitário a ordem em que os testes são executados não deveriam
afetar o resultado final. A ordenação dos testes é importante para a realização dos
testes de integração, onde se verifica a integração entre as unidades e a
dependência entre os componentes.

MOCK DE OBJETOS
O termo Mock Objects é usado para descrever um caso onde um objeto
(mock) é criado para simular um objeto real para teste. O Mock é bastante utilizado
para a realização de TDD (Test-Driven Development), que consiste em realizar os
testes antes da implementação, existindo a necessidade de simular alguns objetos
para se conseguir testar o código.
Em testes unitários é possível imitar o comportamento de objetos reais mais
complexos, também sendo muito utilizados para objetos que geram resultados
variados, objetos com estados difíceis de serem criados/reproduzidos, objetos
lentos (banco de dados) que necessitam serem inicializados antes do testes, objetos
que terão seus comportamentos alterados ou que sequer existam ainda, objetos que
precisam de métodos/informações adicionais para a realização do teste etc.

FLUENT ASSERTIONS
Cria Asserts mais “literais”, tornando a leitura e a interpretação do código
mais simples.
 TDD - Test Driven Development

TDD é o desenvolvimento orientado por testes, ou seja, os testes são escritos

antes mesmo do código de produção. Basicamente o Test Driven Development se
baseia em ciclos de repetição, onde para cada funcionalidade do software um teste é
criado inicialmente para falhar, já que ainda não há uma funcionalidade
implementada. Após isso, o código é feito para fazer o teste passar, porém não para
por aí, este código ainda precisa ser refatorado para garantirmos as boas práticas e
um código limpo.

RED, GREEN e REFACTOR

● Escrevemos um teste que inicialmente não passa (red);
● Adicionamos uma funcionalidade ao sistema;
● Fazemos o teste (criado anteriormente) passar (green);
● Refatoramos o código criado;
● Escrevemos o próximo teste;
 Temos uma nova funcionalidade no sistema e fazemos o processo inverso,
primeiro testamos e depois codificamos, isso faz com que criemos um código mais
simples para que ele apenas passe no teste criado. Inicialmente esse teste irá falhar
pois não há uma implementação ainda, fazendo com que temos apenas um objetivo
agora, fazer este teste passar.
Keep it simple, stupid, o código deve ser escrito da forma mais simples
possível (limpo, simples e funcional). Neste primeiro momento não devemos focar
em boas práticas, inversão de controle, Patterns, etc o código deve ser escrito da
maneira mais simples possível para fazer com o que nosso teste criado
anteriormente passe(sem quebrar outros testes).
CÓDIGO QUE FUNCIONA ------> CÓDIGO SIMPLES E LIMPO ------> CÓDIGO RÁPIDO
Agora é a hora de analisar o código criado, retirando duplicidade, renomeando
variáveis, extraímos classes, métodos, interfaces etc. É na refatoração que
buscamos deixar a implementação simples, clara e funcional. Com isso temos um
teste que nos indicará qualquer movimento errado que for realizado ao melhorarmos
o código, e não apenas este, com o tempo será criada uma Suíte de Testes, o que
permitirá refatorar implementações sem o medo de atingir de forma negativa algum
código já existente, pois já haverá testes para verificar qualquer possível falha.
Single Responsability Principle, este princípio nos diz que cada classe apenas
pode ter uma responsabilidade. O TDD reforça este princípio, tornando os testes
mais simples, já que não podemos refatorar um código e quebrar vários outros
testes ao mesmo tempo.