Testes Unitários

Basis Tecnologia da Informação S.A. - 2019

Porque Testar?

Os teste devem ser escritos a fim de evitar problemas com evoluções realizadas ao longo da fase de desenvolvimento das aplicações, a implementação dos testes nos dá uma visão completa do impacto que determinada manutenção e ou modificações de uma determinadas funcionalidades podem afetar seu sistema.

Tipos de Teste

Caixa Preta
Caixa Branca

Metodologias de Teste

Unit Test
TDD
BDD

Unit Test

Teste de Unidade ou Teste unitário é o responsável por testar cada unidade da aplicação isoladamente

Functional Test

Functional Test ou Teste Funcional é responsável por testar funcionalidades (requisitos funcionais) da aplicação, considerando apenas a sua entrada e sua saída.

Integration Test

Integration Test ou Teste de Integração é responsável por testar funcionalidades da aplicação considerando a interação entre os seus componentes.

Acceptance Test

Acceptance Test ou Teste de Aceitação é responsável por testar funcionalidades da aplicação levando em consideração os requisitos originais da aplicação em relação ao produto final.

TDD

Test Driven Development ou Desenvolvimento orientado a Testes

Implica na escrita dos testes antes do desenvolvimento da aplicação de fato, estes testes falham intencionalmente e ao decorrer do desenvolvimento das funcionalidades da sua aplicações tais testes iram ser bem sucedidos. Esta técnica permite saber quais serão os comportamentos das funcionalidades previamente a implementação das mesmas.

Ciclo de Vida

BDD

Behavior Driven Development ou Desenvolvimento orientado a comportamento Há dois tipos, sendo eles:

StoryBDD
SpecBDD

StoryBDD

Se preocupa mais com o comportamento de mais alto nível da aplicação

Exemplo: Checar se um determinado relatório é gerado e enviado por e-mail.

SpecBDD

Se preocupa mais com o comportamento de baixo nível da aplicação

Exemplo: Checa se determinado método gera corretamente um relatório a partir de um conjunto de dados e o envia por e-mail corretamente.

Diferenças

A diferença entres os dois está no escopo e na visão negocial, pois o StoryBDD possui uma visão mais gerencial

Exemplo: Essa funcionalidade deve gerar um relatório e me enviar por e-mail. Já o SpecBDD possui uma visão mais voltada para a funcionalidade em si

Exemplo: Este método deve receber um array de dados gerar um PDF e o envia-lo por e-mail.

Quando Testar

É recomendável que se realize os testes durante todo o ciclo de vida da aplicação.

O que testar?

"Teste tudo aquilo que possa quebrar"

Kent Beck (XP, Agile, TDD)

Dublês de Teste

Mock

É um objeto que assume o papel de um outro objeto e registra as chamadas que ele recebe e permite verificação à posteriori das chamadas que recebeu.

Stub

É um objeto com estado pré-definido e comportamento fixo e previsível.

Spy

É um objeto semelhante ao Mock, mas não necessariamente subscreve o objeto inteiro. Pode ser criado à partir de objetos reais e subistituir somente os comportamentos desejados do objeto real.

Fake

É um objeto que contém implementação, geralmente diferente e/ou simplificada em relação a implementação de produção. (InMemDB)

Dummy

É um objeto cujo único intúito é preencher lacunas de dados. (Placeholder)

Ferramentas de Teste

Os exemplos em PHP contidos neste treinamento irão utilizar o PHPUnit como framework de teste.

Os exemplos em .NET contidos neste treinamento irão utilizar como base o xUnit como framework de teste.

Instalação (PHP)

Instalando o Xdebug

$ sudo pecl install xdebug
$ php -m
$ sudo service apache2 restart

Instalando o PHPUnit

$ composer require –-dev phpunit/phpunit

Configuração (PHP)

Para começar a usar o PHPUnit iremos criar um arquivo de configuração chamado phpunit.xml na raiz do projeto, veja o exemplo:

<?xml version="1.0" encoding="UTF-8"?>
<phpunit colors="true">
        <phpunit bootstrap="tests/bootstrap.php"></phpunit>
    <testsuites>
        <testsuite name="UnitTestSuite">
            <directory suffix=".php">tests</directory>
        </testsuite>
    </testsuites>
    <filter>
        <whitelist>
            <directory suffix=".php">src/</directory>
            <exclude>
                    <directory suffix=".php">./src/*/Repository</directory>
                <directory suffix=".php">./vendor/</directory>
            </exclude>
        </whitelist>
    </filter>
    <logging>
            <log type="coverage-html" target="files/tests-clover.html"/>
        <log type="coverage-clover" target="files/tests-clover.xml"/>
        <log type="junit" target="files/tests-junit.xml" logIncompleteSkipped="false"/>
    </logging>
</phpunit>

Configuração (PHP)

Configurando o arquivo composer.json

{
        "name" : "unit/test",
        "description" : "TesteDeUnidade",
        "authors" : [{
                        "name" : "Jonathan Monteiro",
                        "email" : "jonathan.silva@basis.com.br"
                }
        ],
        "require" : {
                "phpunit/phpunit" : "^6"
        },
        "autoload" : {
                "psr-4" : {
                        "" : "src"
                }
        },
        "autoload-dev" : {
                "psr-4" : {
                        "Tests\\" : "tests"
                }
        }
}

Instalação & Configuração (.NET)

https://www.nuget.org/

Install-Package xunit
Install-Package ExpectedObjects
Install-Package Bogus
Install-Package Moq

Cobertura de Código com PHPUnit:

Essa uma feature do PHPUnit que nos permite ter uma visualização gráfica do quanto nosso código foi testado, a porcentagem de cobertura dos testes e outras informações como:

Complexidade Ciclomática
Distribuição de Cobertura
Complexidade do Método

Executando Testes

Exemplos práticos