Forem: Thalita Marra

Testes de Contrato

Thalita Marra — Fri, 29 Sep 2023 18:46:43 +0000

Tive a fantástica oportunidade de poder compartilhar um pouco dos meus problemas e estudos atuais na forma de uma palestra no PHP Community Summit 23 (galera do PHPSP, vcs arrasam!) e fiquei devendo compartilhar a apresentação com a comunidade, então aqui está:

Testes de Contrato - PHP Summit - Google Slides

docs.google.com

// TODO voltar e colocar o video do YouTube 😅

Depois de sei lá quanto tempo estar de volta à comunidade que me acolheu alguns anos atrás foi super gratificante e inspirador 💙

Espero que o conteúdo também seja relevante pra vocês e fico à disposição :)

Git e GitHub

Thalita Marra — Fri, 24 Feb 2023 23:03:15 +0000

O que é Git
Onde o GitHub entra nessa história
Como isso se encaixa no dia a dia de uma pessoa desenvolvedora
- Concluir as configurações necessárias
- Iniciar o projeto com o Git
- Atuar no projeto
- Salvar minhas alterações
- Juntar o código novo com o código principal
- Atualizar o projeto local
Resumindo

O que é Git

Segundo nossa querida Wikipedia, o Git é um sistema de controle de versões distribuído.

E o que isso significa?

Deixa eu tentar explicar com um exemplo:

Suponha que estamos trabalhando em uma plataforma muito grande, onde funcionalidades são atualizadas e criadas constantemente. Em determinado momento alguém fala para apagarmos uma funcionalidade que era difícil de manter e não estava sendo usada. Fazemos isso, simplificamos bastante coisa no nosso código e seguimos criando e atualizando outras coisas. Meses se passam e um belo dia alguém fala que vai precisar daquela funcionalidade que apagamos. E agora?

Se nosso projeto estiver usando o Git, podemos voltar na ramificação que tinha aquela funcionalidade (aquele “controle de versão” da definição da Wikipedia) e pensar em estratégias para integrar esse código apagado novamente. Não seria necessário criar tudo do zero.

Com o Git, cada pessoa que tiver clonado o repositório terá uma cópia local do histórico completo da versão do projeto. Alterações podem ser feitas na sua máquina e enviadas para o repositório principal depois, assim várias pessoas podem atuar no projeto ao mesmo tempo (inclusive no mesmo arquivo) sem que uma alteração afete os outros.

Onde o GitHub entra nessa história

O GitHub é uma plataforma que usa Git. É como se alguém tivesse baixado o Git em um servidor, feito uma tela maneira, colocado algumas funcionalidades a mais e disponibilizado em nuvem pra gente usar. Assim como o GitHub, existem várias outras plataformas que usam o Git por trás dos panos, como o GitLab e Bitbucket.

Como isso se encaixa no dia a dia de uma pessoa desenvolvedora

Falando sobre o meu dia a dia enquanto desenvolvedora, muita coisa gira ao redor do Git / GitHub.

Concluir as configurações necessárias

Após instalado, precisamos configurar o Git. Sua configuração inicial precisa incluir o nome e email da autoria de mudanças enviadas por determinada máquina.

git config - as configurações do Git precisam ser feitas apenas uma vez se usarmos a opção --global ou por diretório se usarmos a opção --local. Existe uma lista enorme de coisas que podemos configurar, mas as principais são o nome (git config --global user.name "Seu Nome") e email (git config --global user.email "seu@email.com")

Iniciar o projeto com o Git

Logo que começo a atuar em um projeto, uma das primeiras coisas a fazer é clonar o repositório e ler as instruções (normalmente encontradas no arquivo README.md na raiz do projeto).

git clone url_do_projeto - clonar um projeto significa fazer uma cópia do repositório na minha máquina, para que eu possa acessá-lo e atuar nele localmente. Normalmente é uma ação feita apenas uma vez por projeto.

O GitHub tem uma documentação boa sobre como clonar projetos. A minha opção preferida é clonar via SSH já que não preciso ficar validando minha identidade repetidamente. O GitHub também tem uma documentação detalhando como isso funciona.

Caso seja um projeto 100% novo, posso criar a base dele na minha máquina para então iniciar o Git localmente e enviar para o repositório no GitHub.

git init - iniciar um repositório também costuma ser uma ação feita apenas uma vez. Esse comando vai criar uma pasta chamada .git na raiz do projeto contendo todos os metadados do repositório e habilitar o uso dos demais comandos do git para aquele projeto.

Para criar o repositório no GitHub, basta seguir a documentação deles que não tem muita surpresa.

Atuar no projeto

Uma vez que tenho o código disponível na minha máquina, posso começar a atuar em alterações. Para isso crio uma nova ramificação (ou branch) a partir da ramificação principal, normalmente chamada de main.

Um branch é um snapshot do código em determinado momento, uma "cópia" isolada do código tal qual está. Dessa forma podemos testar coisas, mudar comportamentos, etc, sem que nossas ações afetem as demais versões do projeto.

git checkout -b minha-tarefa - o comando git checkout, quando usado dessa forma, é responsável por mudar de branch; a opção -b criará um novo branch com o nome informado a seguir (nesse exemplo, minha-tarefa).
Vale comentar aqui que o -b veio como uma forma de chamar o comando git branch (que lista, cria, renomeia e exclui branches) junto ao git checkout.

Salvar minhas alterações

Gosto de separar meu desenvolvimento em fases. Então assim que termino partes do que estou fazendo posso "nomear" aquele pacote de alterações e criar um histórico de coisas que executei.

git add [nome dos arquivos] - primeiro é necessário falar quais arquivos vou incluir em determinado "pacote" de alteração, seja colocando o nome dos mesmos separados por espaço (ex.: hello.html hello.css), seja usando um . para incluir tudo de determinado diretório, ou --all para adicionar todos os arquivos alterados em todos os diretórios.

git commit -m "uma mensagem" - depois de ter todos os arquivos selecionados, preciso adicionar uma mensagem que explica a alteração que foi feita.

Usando esses comandos, se alguma alteração que fiz der errado, posso consultar o histórico do meu branch e voltar para determinado ponto do desenvolvimento, se necessário for.

Bem, até então tudo o que foi desenvolvido está apenas na minha máquina e preciso enviar isso para o GitHub (ou qualquer outra plataforma que estiver usando). Normalmente costumo enviar as alterações que fiz ao final do dia (vai que minha máquina pega fogo, nunca se sabe...) ou quando o desenvolvimento está concluído.

git push origin minha-tarefa - aqueles commits que fiz anteriormente serão "empurrados" do branch minha-tarefa da máquina local para o ambiente remoto (o repositório "origem" no GitHub), em um branch que também será chamado de minha-tarefa.

Dá pra usar o comando git push de algumas formas diferentes. Achei um artigo da Trybe muito maneiro que entra em mais detalhes, caso queira.

Juntar o código novo com o código principal

Uma vez que terminei tudo o que tinha para fazer naquela tarefa posso abrir um Pull Request (ou PR). Em resumo, o PR vai disponibilizar o código que eu criei para ser revisado por outras pessoas que trabalham comigo (e por mim mesma também) e, caso esteja tudo certo, juntá-lo ao código principal (ação chamada merge).

Na imagem estamos abrindo um Pull Request no GitHub. Queremos juntar nosso código no código principal, então configuramos a base como main (o branch principal) e comparamos com o branch que atuamos, minha-tarefa. Para que as outras pessoas saibam o que aquele PR trata, colocamos um título resumindo a tarefa que estamos entregando e uma descrição explicando o objetivo daquele código, dando exemplos de como testar, adicionando detalhes importantes sobre as regras que aquele código deve seguir, etc.

O GitHub tem uma documentação bem detalhada sobre como funciona esse processo. Existem várias customizações que podem ser feitas, é bem legal.

Atualizar o projeto local

Uma vez que terminei minhas alterações, preciso voltar para o branch principal e buscar a versão mais atual dele, para, só então, começar a trabalhar em uma nova tarefa.

git checkout main - usado para voltar ao branch principal. Aqui não é necessário usar a opção -b pois a ramificação main já existe.
git pull origin main - "puxa" para a máquina local todas as alterações que estiverem no branch main da origem, o repositório no GitHub.

Resumindo

É difícil colocar todos os comandos do Git em um único post, mas esses são os principais do meu dia a dia. Vou deixar um resumo para download pra facilitar o acesso:

Se aparecer qualquer dúvida pode colocar aqui nos comentários que tento responder assim que possível.

Até a próxima!

5 dicas de como escrever um bom desafio técnico

Thalita Marra — Mon, 28 Jun 2021 18:49:49 +0000

Olá olá!

Esses dias estava passeando pelos meus repositórios do GitHub e vi um dos últimos desafios técnicos que fiz por lá. Refletindo um pouco sobre ele e sobre tudo o que eu aprendi enquanto entrevistadora técnica na minha empresa atual decidi fazer um compilado de dicas que eu daria pra mim mesma naquela época.
Bem, lhes apresento a minha lista de 5 dicas de como escrever um bom desafio técnico:

Entenda o problema

Durante o desafio técnico (seja escrevendo código ou whiteboard), a primeira coisa que precisa ficar clara é qual o problema que você vai ter que resolver. Quanto menor for o seu nível de dúvidas, maior é a possibilidade de entregar uma solução assertiva e, ouso dizer, gerando uma entrega com mais confiança até.

Os envolvidos na entrevista técnica estão preparado para tirar suas dúvidas e (pelo menos nas entrevistas que já participei) isso não afeta em nada o resultado daquela etapa. Pode perguntar sem medo!

Aqui também vale destacar a importância de confirmar se todos os contratos estão sendo cumpridos uma vez que a solução estiver pronta.

Se o desafio for escrever uma API por exemplo, confirme se os retornos, rotas e validações estão de acordo com o descrito no problema, veja se os pré-requisitos funcionais e não funcionais do código foram atendidos.

Um detalhe importante é que não é incomum seu projeto ser testado de forma automática. Então se no desafio você precisa criar uma rota para a url /create-user e você escreve /createUser, pode ser que o teste não passe e isso acabe te atrapalhando. Novamente, confirme se os requisitos foram atendidos.

Não deixe de entregar seu desafio porque não conseguir completá-lo. O ideal é entregar tudo de acordo com o que foi pedido, mas não é impossível passar em uma vaga sem ter concluído 100% do desafio.

Explique seu repositório

Nada me deixa mais triste com um repositório do que a falta de documentação. O que eu preciso instalar pra fazer o projeto rodar? Quais comandos eu preciso chamar para conseguir fazer o que precisa? Existe Docker? Tem alguma coisa de fora da linguagem que eu preciso? Alguma configuração?

É extremamente importante que a pessoa que vai avaliar sua solução consiga saber facilmente como ela funciona. Inclusive pessoas de outros lugares. Seu GitHub, GitLab, Bitbucket, etc, é um portfólio e pode ser seu grande aliado.

Tire um tempo para atualizar o README e, pelo menos, explicar a ideia geral do projeto, como instalar e como utilizar. E confirme se tudo funciona conforme o descrito.

Destaque para a lógica

Muitas vezes vemos nas vagas alguma menção à framework. Então assumimos que para escrever uma boa solução precisaremos usar aquele framework e demonstrar nosso conhecimento sobre ele. Só que nem sempre é assim.

Quem vai avaliar precisa entender como é seu processo criativo, o que você pensou até chegar em uma solução e como você trabalha.

O uso de um framework me faz lembrar de dois possíveis problemas logo de cara:

Às vezes a solução enviada está tão acoplada com as funcionalidades existentes no framework que é impossível avaliar como é o código de quem entregou. Código gerado pelo framework é bem diferente do código que nós escrevemos no dia a dia.
Quando uma solução depende demais das features disponíveis no framework pode ser que a solução enviada seja muito mais complexa do que o necessário.

Não é ruim usar frameworks ou bibliotecas, mas crie algo que demonstre sua linha de raciocínio, algo que você entenda porque funciona, como funciona, que você acredita que seja a forma mais otimizada de resolver algo e que vai saber explicar posteriormente.

Demonstre conhecer a tecnologia utilizada

Aqui é meio que uma extensão da dica anterior. Demonstrar que você conhece funcionalidades da linguagem escolhida que não estão no framework vai te ajudar, conseguir explicar porque usou determinado banco ou determinada biblioteca também vai te ajudar.

Saiba os motivos pelos quais está usando a tecnologia que você escolheu. Pode ser que você esteja aplicando para uma vaga de níveis iniciais e só usou o MySQL porque está acostumado com isso, então esse é seu motivo e tudo bem. Mas a medida que o nível das vagas vai aumentando, essa exigência também vai aumentando, então questione as decisões que você toma automaticamente e veja se fazem sentido para o contexto do desafio proposto.

Lembre-se das melhores práticas

Um código bom é um código que funciona e que também é legível. Não existe essa de que só funcionar está bom, ainda mais em um momento onde seu código é avaliado.

Algumas vagas, pelo menos na minha bolha de PHP, fazem menção a algo chamado PSR (PHP Standard Recommendation) que nada mais é do que uma lista de boas práticas para escrita de código. Fala sobre formatação, nomenclaturas, estilo de código, etc. Esse é um detalhe que costuma ser visto com bastante carinho, não necessariamente uma exigência, mas algo que vai te ajudar.

Veja se a linguagem que está usando também possui um guia de melhores práticas e se atenha a elas. Deixe seu código legível, use terminologias com consistência, escolha bons nomes para classes, funções e variáveis e não escreva comentários sem necessidade.

Bom, é isso. Espero que seja de alguma ajuda. Se quiserem deixar mais dicas aqui nos comentários ou tirar alguma dúvida, o espaço é nosso!

Até a próxima!

Introdução ao desenvolvimento guiado por testes (TDD)

Thalita Marra — Mon, 14 Jun 2021 18:33:11 +0000

Olá olá!

Essa é a última postagem da série de Introdução a Testes de Software e quero terminar plantando a sementinha do TDD no arsenal de vocês 🌱

O que é TDD?

TDD é uma sigla para Test Driven Development (ou Desenvolvimento Guiado por Testes) que na prática significa exatamente o que o nome diz: primeiro escrevemos os testes, depois o código de produção.

Colocar o TDD em prática significa trabalhar de forma cíclica: primeiro criamos os testes necessários, que irão falhar; depois vamos escrever o mínimo possível de código para os testes passarem; por fim, se necessário, refatoramos o que foi feito. Bem simples!

A princípio pode parecer meio complexo, mas vamos ver um exemplo prático e vai ficar mais claro uma vez que chegarmos lá.

Modelo F.I.R.S.T.

Quando seguimos o ciclo do TDD é normal ter uma quantidade considerável de testes cobrindo praticamente todo o nosso código de produção.

Chega um momento em que o tamanho dos testes acompanha o tamanho do código de produção, e isso pode se tornar um problema de gerenciamento assustador. Sendo assim, é necessário tratar os testes com o mesmo cuidado que o código de produção.

O modelo F.I.R.S.T. existe para ajudar nesse processo e cada letra do acrônimo representa um princípio a ser seguido:

Fast (rapidez): os testes devem ser rápidos. Quando eles são lentos se torna tentador não executá-los com frequência, trazendo problemas como encontrar um bug tardiamente, quando for mais difícil de concertá-lo ou quando ele já afetar outras áreas.
Isolates (isolamento): um teste não deve depender de outro, eles precisam ser executados de forma independente e em qualquer ordem. Dessa forma fica fácil de encontrar onde e porque alguma falha acontece.
Repeateble (repetitividade): devemos ser capaz de executar os testes unitários em qualquer ambiente, com resultados e comportamentos constantes. Eles não devem depender de algum estado prévio (de um banco de dados já preenchido, por exemplo) e devem deixar o ambiente tal qual estava antes de serem iniciados. Devem rodar com ou sem internet, no seu ambiente local ou no ambiente de produção. Se um teste não roda fora de um ambiente específico, eles não vão te ajudar em todas as situações que poderiam.
Self-validating (autovalidação): os testes devem resultar em sucesso ou erro, eles não podem depender de alguém validando seu resultado manualmente. Um resultado de erro ou sucesso não deve ser subjetivo.
Timely (pontualidade): os testes precisam ser escritos no momento certo. No TDD é importante que o teste seja feito antes do desenvolvimento do código de produção. Deixar o teste para depois pode fazer com que eles sejam ignorados ou que não cubram quantos casos poderiam se o fluxo correto fosse seguido.

Exemplo prático

Precisamos desenvolver um sistema de biblioteca e vamos começar pelo cadastro dos livros. Os requisitos são:

01: A biblioteca deve possuir livros
02: Deve ser possível navegar por todos os livros disponíveis na biblioteca

Então seguindo o ciclo do TDD, começamos escrevendo um teste de falha:

01.01. Criar um teste que falhe (vermelho)

Vamos começar a descrever nossa regra de negócio através do teste:

public function testBibliotecaPossuiLivros(): void
{
    $book = new Book('Aqueles olhos verdes', 'Pedro Bandeira');

    $library = new Library();

    self::assertEmpty($library->nextBook());

    $library->add($book);

    self::assertEquals($book, $library->nextBook());
    self::assertCount(1, $library);
}

Quando o PHPUnit executar nosso teste iremos receber um erro:

PHPUnit 9.5.5 by Sebastian Bergmann and contributors.

E                                                                   1 / 1 (100%)

Time: 00:00.064, Memory: 4.00 MB

There was 1 error:

1) Tests\BooksTest::testBibliotecaPossuiLivros
Error: Class "Tests\Book" not found

/app/tests/BooksTest.php:13

ERRORS!
Tests: 1, Assertions: 0, Errors: 1.

Como a única coisa que fizemos até então foi criar o teste, precisamos criar as classes e métodos necessários para fazer o teste passar.

01.02. Fazer os testes passarem (verde)

Começamos criando a classe Book e como a única coisa que precisamos nesse momento é a classe com o construtor, então ficou algo bem genérico:

<?php

namespace App;

class Book
{
    private string $name;
    private string $author;

    public function __construct(string $name, string $author)
    {
        $this->name = $name;
        $this->author = $author;
    }
}

Já a classe Library precisa do método count() para passar no assertCount. Vamos implementar a interface nativa do PHP Countable para resolver essa etapa. Também precisamos do método add() para salvar o livro na biblioteca e do método nextBook() para iterar sobre os livros disponíveis.

<?php

namespace App;

class Library implements \Countable
{
    private array $books = [];

    public function add(Book $book): void
    {
        $this->books[] = $book;
    }

    public function count(): int
    {
        return count($this->books);
    }

    public function nextBook(): ?Book
    {
        return empty($this->books) ? null : $this->books[0];
    }
}

Da forma que a classe Library foi criada, o método nextBook retorna apenas o primeiro livro existente na biblioteca, quando houver. Não precisamos nos preocupar com isso agora porque não temos nenhum teste validando o processo de iteração nos livros, precisamos apenas que os testes passem:

PHPUnit 9.5.5 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 00:00.068, Memory: 4.00 MB

OK (1 test, 3 assertions)

01.03. Refatorar o código escrito (azul)

Agora sim fazemos melhorias naquele código que escrevemos anteriormente. Como ainda é o começo do nosso sistema e não tem muita coisa para mexer, talvez nem fosse preciso refatorar nada, mas vamos colocar um operador ternário no método nextBook para diminuir um pouco o código:

public function nextBook(): ?Book
{
    return $this->books[0] ?? null;
}

E rodamos o teste novamente para ter certeza de que nada quebrou:

PHPUnit 9.5.5 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 00:00.067, Memory: 4.00 MB

OK (1 test, 3 assertions)

Agora precisamos fazer com que a segunda parte dos nossos requisitos seja atendida: o método nextBook deve navegar por todos os livros disponíveis na biblioteca.

02.01. Criar um teste que falhe (vermelho)

Vamos criar um roteiro de como o sistema deveria funcionar, criando os livros, adicionando eles à biblioteca e passando por todos os ítens disponíveis:

public function testNavegarPorTodosOsLivros(): void
{
    $book1 = new Book('O Mundo de Sofia', 'Jostein Gaarder');
    $book2 = new Book('O Silmarillion', 'J. R. R. Tolkien');

    $library = new Library();
    $library->add($book1);
    $library->add($book2);

    self::assertEquals($book1, $library->nextBook());
    self::assertEquals($book2, $library->nextBook());
}

Ao executar esse teste no PHPUnit vemos que ele irá falhar:

PHPUnit 9.5.5 by Sebastian Bergmann and contributors.

F                                                                   1 / 1 (100%)

Time: 00:00.087, Memory: 4.00 MB

There was 1 failure:

1) Tests\BooksTest::testNavegarPorTodosOsLivros
Failed asserting that two objects are equal.
--- Expected
+++ Actual
@@ @@
 App\Book Object (
-    'name' => 'O Silmarillion'
-    'author' => 'J. R. R. Tolkien'
+    'name' => 'O Mundo de Sofia'
+    'author' => 'Jostein Gaarder'
 )

/app/tests/BooksTest.php:35

FAILURES!
Tests: 1, Assertions: 2, Failures: 1.
ERROR: 1

Aqui o PHPUnit falou que fez duas afirmações e apenas uma delas falhou (Assertions: 2, Failures: 1). Isso foi porque o primeiro item sempre está retornando, então pesquisar apenas pelo primeiro item iria funcionar. O problema está quando vamos pesquisar a partir do segundo item.

02.02. Fazer os testes passarem (verde)

Vamos mexer na classe Library para que o método nextBook passe por todos os livros disponíveis:

<?php

namespace App;

class Library implements \Countable
{
    private array $books = [];
    private int $nextBookIdx = 0;

    public function add(Book $book): void
    {
        $this->books[] = $book;
    }

    public function count(): int
    {
        return count($this->books);
    }

    public function nextBook(): ?Book
    {
        if(isset($this->books[$this->nextBookIdx])) {
            $book = $this->books[$this->nextBookIdx];
            $this->nextBookIdx++;

            return $book;
        }

        return null;
    }
}

Adicionamos à classe uma variável chamada $nextBookIdx que represente qual o índice do próximo livro a ser retornado e usamos essa variável na função nextBook(), retornando o livro correspondente caso ele exista.

Ao chamar o PHPUnit vemos que tanto o novo teste quanto o anterior estão passando:

PHPUnit 9.5.5 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 00:00.068, Memory: 4.00 MB

OK (2 tests, 5 assertions)

02.03. Refatorar o código escrito (azul)

Como a variável $nextBookIdx só é usada dentro do nextBook() e $books é um array, podemos usar as funções nativas do PHP current() e next() para resolver a navegação, removendo a necessidade da variável $nextBookIdx:

<?php

namespace App;

class Library implements \Countable
{
    private array $books = [];

    public function add(Book $book): void
    {
        $this->books[] = $book;
    }

    public function count(): int
    {
        return count($this->books);
    }

    public function nextBook(): ?Book
    {
        $book = current($this->books);

        if($book) {
            next($this->books);
            return $book;
        }

        return null;
    }
}

Para quem ainda não está familiarizado com essas funções do PHP, a documentação explica muito bem o que elas fazem, mas de forma geral o que acontece é o seguinte:

Cada array possui um ponteiro interno para seu elemento atual, que é inicializado para o primeiro elemento inserido no array. O método current() retorna o elemento atual ou false caso não exista nada para retornar.
A função next() avança o ponteiro, retornando false caso não exista um próximo item.

Confirmamos que os testes permanecem sem erros:

PHPUnit 9.5.5 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 00:00.066, Memory: 4.00 MB

OK (2 tests, 5 assertions)

Se fosse preciso adicionar novas funcionalidades ao sistema continuaríamos nesse mesmo fluxo: criar um teste de falha → escrever o mínimo de código para fazer teste passar → melhorar o código. Não tem muito segredo.

Por que usar?

Todo esse processo pode parecer tedioso mas essa prática nos traz muitos benefícios durante o desenvolvimento e manutenção do sistema. Para finalizar queria deixar aqui os benefícios que percebi enquanto usava o TDD:

Qualidade de código

"Se algo não é possível ser testado, então foi desenvolvido de forma ruim."

— Código Limpo, cap. 09

Se nós criamos um código com muito acoplamento ou de alta complexidade não vamos querer testá-lo porque vai dar muito trabalho ou vai ser totalmente inviável. Começar escrevendo o teste e apenas o mínimo de código necessário nos força a pensar em como fazer as coisas de maneira mais simples e desacoplada possível.

Entendimento sobre o problema

Para escrever um teste nós precisamos entender bem o problema que estamos resolvendo e qual resultado queremos chegar. Descrever a ideia através do teste é como criar um roteiro dizendo como a aplicação precisa funcionar. Dessa forma não criamos coisas nem de mais e nem de menos, já criamos um código voltado para a solução esperada.

Segurança e produtividade

Quando a gente altera um código existe a chance dessa alteração causar algum tipo de imprevisto. Quando temos uma aplicação com alta cobertura de testes automatizados essa chance é menor. E se não precisamos nos preocupar tanto em quebrar alguma coisa ou em fazer testes manuais, sentimos mais segurança naquilo que estamos fazendo e ganhamos tempo para outras atividades.

Existe também o benefício de quando uma pessoa nova entra no time ou quando voltamos a mexer em um código que não vemos há semanas, os testes vão lembrar de todas as excessões que podem acontecer, todas as situações que precisam funcionar de certa maneira. Todos os contratos de como a aplicação deve funcionar estão assegurados.

Documentação

Os testes do seu código podem ser a melhor documentação que você vai ter. Eles te dizem o que funciona, como funciona, quais dependências estão envolvidas, quais os possíveis fluxos de erros, etc. E através do TDD, seus testes sempre estarão tão ou mais atualizados quanto o desenvolvimento, não haverá nenhum atraso.

Bom, é isso. Como sempre, se ficou alguma dúvida pode deixar aqui nos comentários que eu respondo assim que possível!

Se quiserem baixar o código é só acessar o repositório no GitHub. Cada etapa do ciclo que fizemos aqui pode ser encontrada lá na lista de branches ou de commits.

Fico por aqui e até a próxima!

Fonte:

Documentação do PHP

PHP Testing Jargon, Laracasts.

F.I.R.S.T, Tim Ottinger & Jeff Langr

Testes Unitários com TDD, Pablo Rodrigo Darde.

Livro: Código Limpo, Robert C. Martin

Test doubles

Thalita Marra — Mon, 07 Jun 2021 17:48:59 +0000

Recorrendo a Test Doubles
Quais Test Doubles existem?
Test Doubles e Refatoração
Cuidado com o SUT

Olá olá!

Hoje eu quero falar de algo que me confundiu muito quando comecei a aplicar testes: como eu faço pra substituir coisas desnecessárias ao objetivo do teste? Quais conceitos preciso entender para escrever os testes de forma que meus pares também entendam?

Imagine que você está desenvolvendo uma integração com algum meio de pagamento (PayPal, Mercado Pago, etc.) e precisa testar essa classe.

Podemos criar os testes sem alterar nada no código e continuar chamando a integração. Fazer isso vem com vários problemas como criar uma dependência do nosso teste no serviço externo, aumentar o tempo de execução da rotina de testes, pode afetar algum limite de requisição que o serviço imponha, e por ai vai...

Podemos criar nossos testes ignorando todas as etapas que utilizam o serviço externo, mas assim vamos acabar ignorando parte da lógica interna. Como testar se o banco de dados está sendo atualizado depois que o pagamento foi feito com sucesso? Como confirmar que os tratamentos de erro estão funcionando conforme o esperado?

Recorrendo a Test Doubles

O termo Test Doubles foi descrito no livro XUnit Test Patterns: Refactoring Test Code, de Gerard Meszaros e representa qualquer objeto que simula um objeto real para fins de teste.

Quando escrevemos nossos testes e nos deparamos com casos onde não podemos usar um componente real ou casos onde não seria prático usá-lo, podemos substituí-lo por um Test Double. Os test doubles não precisam ser exatamente como o componente real, precisam apenas se comportar de tal forma que o sistema sobre teste (System Under Test ou SUT) pense que ele é real.

Vamos para um exemplo prático?

Precisamos fazer um sistema de assinatura que pode ter vários meios de pagamento.

Uma forma de executar isso é criando uma classe de integração para cada meio de pagamento e padronizá-las através de uma interface, chamada Gateway, para garantir que todas as classes respeitem o mesmo contrato.

Esse contrato é dividido em três funções: register, que cria um novo registro do nosso usuário na plataforma de pagamento, activate, que ativa a assinatura, e deactivate, que inativa a assinatura quando o usuário quiser cancelar seu plano:

<?php

namespace App;

interface Gateway
{
    public function register(string $email): void;

    public function activate(): string;

    public function deactivate(): void;
}

Com a interface Gateway padronizamos como será feita a integração com o meio de pagamento, mas agora precisamos resolver as nossas regras de negócio.

Para isso temos a classe Subscription que será responsável por chamar a integração, o gerenciamento do usuário e enviar um email de confirmação da assinatura. Isso tudo será feito dentro de uma função chamada create:

<?php

namespace App;

class Subscription
{
    protected Gateway $gateway;
    protected Mailer $mailer;

    public function __construct(Gateway $gateway, Mailer $mailer)
    {
        $this->gateway = $gateway;
        $this->mailer = $mailer;
    }

    public function create(User $user): void
    {
        $this->gateway->register($user->email);

        $receipt = $this->gateway->activate();

        $user->subscribe($receipt);

        $this->mailer->send($user,'Your receipt number is: ' . $receipt);
    }
}

Temos também a classe User com todos os métodos responsáveis por gerir os dados do usuário do nosso sistema. Essa classe possui o método subscribe, que é responsável por vincular o usuário ao ponteiro do meio de pagamento, e o método isSubscribed, que retorna se aquele objeto possui ou não uma assinatura vinculada.

<?php

namespace App;

class User
{
    public string $email;
    public ?string $subscription;

    public function __construct(string $email)
    {
        $this->email = $email;
        $this->subscription = null;
    }

    public function subscribe(string $subscriptionId): void
    {
        $this->subscription = $subscriptionId;
    }

    public function isSubscribed(): bool
    {
        return is_string($this->subscription);
    }
}

Por fim, criamos uma integração com algum serviço de envio de email chamada Mailer para enviar uma mensagem ao usuário:

<?php

namespace App;

class Mailer
{
    public function send(User $user, string $message): void
    {
        // logica
    }
}

Pronto, esse é o nosso SUT, o sistema que vamos testar. E sem mais delongas, vamos aos test doubles!

Quais Test Doubles existem?

Segundo Gerard Meszaros eles podem ser divididos em cinco categorias: Fakes, Dummies, Stubs, Mocks e Spies.

Fake

Fakes são objetos com implementações funcionais que normalmente usam atalhos para executar ações.

Para não precisar usar a implementação de produção no nosso teste, podemos criar uma classe Fake que respeita o mesmo contrato da classe de produção e usar ela nos nossos testes. Para o nosso exemplo poderia ser uma classe assim:

<?php

namespace Tests;

use App\Gateway;

class GatewayFake implements Gateway
{
    public function register(string $email): void
    {
        //
    }

    public function activate(): string
    {
        return 'some-uuid';
    }

    public function deactivate(): void
    {
        //
    }
}

Ela usa a mesma interface de produção (Gateway), possui os mesmos métodos que são chamados pela classe Subscription, mas não executam nenhuma ação real, possui apenas o suficiente para rodarmos nossos testes.

Dummy

Dummy é um objeto sem nenhuma funcionalidade específica; é usado apenas para preencher parâmetros.

Vamos para o primeiro caso de teste: precisamos validar se o usuário foi atualizado após a ativação da assinatura.

Usando a biblioteca PHPUnit é possível escrever o teste da seguinte forma:

public function testValidaUsuarioComAssinatura(): void
{
    $gatewayFake = new GatewayFake();
    $mailerDummy = $this->createMock(Mailer::class);

    $subscription = new Subscription($gatewayFake, $mailerDummy);
    $user = new User('Maria');

    self::assertFalse($user->isSubscribed());

    $subscription->create($user);

    self::assertTrue($user->isSubscribed());
}

Para não chamar a integração com o meio de pagamento usamos a classe GatewayFake que criamos anteriormente. Como também não precisamos validar nenhum comportamento do envio de email substituímos a classe Mailer por um Dummy criado através do PHPUnit apenas para preencher os requisitos da construção da classe Subscription.

O uso de Fake e Dummy aqui foi apenas uma forma de exemplificar esses dois conceitos. Poderíamos criar um Fake para o envio de email ou um Dummy para a integração com o meio de pagamentos sem problema algum.

💡 Note que o nome da função chamada para criar o Dummy é createMock(...). Não é incomum o uso do termo Mock como sinônimo de qualquer um dos outros test doubles mas ele também tem outra definição, que veremos logo a seguir.

Stub

Stubs são objetos que usamos para simular interações de chegada de alguma dependência externa ao SUT. Eles são usados apenas para fornecer uma resposta programada para aquele teste.

No nosso exemplo a classe de Subscription solicita a ativação da assinatura através da função activate e atualiza o UUID que retornou da integração nos dados do usuário interno.

Para garantir a integridade dos dados do nosso usuário precisamos ter certeza que o valor retornado pela função activate é o mesmo que está sendo salvo no usuário:

public function testValidaValorCorretoAssinatura(): void
{
    $gatewayStub = $this->createStub(Gateway::class);
    $gatewayStub->method('activate')->willReturn('some-uuid');

    $mailerDummy = $this->createMock(Mailer::class);

    $subscription = new Subscription($gatewayStub, $mailerDummy);
    $user = new User('Maria');

    // valida que o usuario foi criado sem assinatura
    self::assertNull($user->subscription);

    $subscription->create($user);

    // valida que o valor salvo no banco é o mesmo retornado pela integração
    self::assertEquals('some-uuid', $user->subscription);
}

Para validar esse cenário precisamos que o método activate retorne uma string correspondente ao UUID externo, portanto criamos um Stub para simular essa interação de chegada.

Como não precisamos validar o envio de email, permanecemos com o Dummy para a classe Mailer.

Mock

Mocks, por sua vez, são objetos que usamos para simular interações de saída. Eles possuem expectativas sobre seu comportamento, ou seja, verificam se um ou mais métodos foram chamados, a ordem e quantidade de vezes que foram chamados, etc, lançando exceções quando o teste não se comporta conforme o esperado.

Vamos testar se o SUT está enviando o email quando a assinatura é criada:

public function testValidaEnvioDeEmail(): void
{
    $this->expectNotToPerformAssertions();

    $user = new User('Maria');

    $gatewayStub = $this->createStub(Gateway::class);
    $gatewayStub->method('activate')->willReturn('some-uuid');

    $mailerMock = Mockery::mock(Mailer::class);
    $mailerMock
        ->shouldReceive('send')
        ->once()
        ->withArgs([$user, 'Your receipt number is: some-uuid']);

    $subscription = new Subscription($gatewayStub, $mailerMock);
    $subscription->create($user);
}

Aqui acabei usando a biblioteca Mockery junto ao PHPUnit para melhorar a legibilidade do código.

Podemos ver no teste acima que logo no começo foi explicito que não haveria nenhum afirmação (assert). Ao invés disso apenas validamos as expectativas da interação de saída do SUT em relação ao serviço externo.

Ou seja, descrevemos nossa expectativa (shouldReceive()) que o serviço de envio de email chamaria o método send, que essa chamada aconteceria apenas uma vez (once()) e que os argumentos passados para o método (withArgs()) seriam o usuário e aquela exata mensagem.

Caso a mensagem ou o objeto $user estejam diferentes do definido no teste, o mesmo iria falhar.

Spy

Spy pode ser definido como uma combinação do Stub com o Mock. Spies validam informações com base em como foram chamados e também permitem testar as interações tanto de chegada quanto de saída.

Diferem dos Stubs e Mocks no fato de que os Spies registram qualquer interação entre ele e o SUT e nos permitem fazer afirmações contra essas interações após o fato.

Usaremos um Spy para garantir que a assinatura foi ativada e não houve nenhuma chamada do fluxo de inativação:

public function testConfirmaAssinaturaAtiva(): void
{
    $this->expectNotToPerformAssertions();

    $gatewaySpy = Mockery::spy(Gateway::class);
    $mailerDummy = $this->createMock(Mailer::class);

    $subscription = new Subscription($gatewaySpy, $mailerDummy);
    $subscription->create(new User('Maria'));

    $gatewaySpy->shouldHaveReceived('activate');
    $gatewaySpy->shouldNotHaveReceived('deactivate');
}

Logo no começo foi definido que não haveria nenhuma afirmação, já que não faz parte do objetivo do teste. E como não precisamos testar nada do fluxo de envio de email, voltamos a usar um Dummy para a classe Mailer.

O Spy que substituiu o gateway de pagamento verifica depois de todo o fluxo executado quais funções foram chamadas e quais não foram, validando que houve uma chamada para a função activate e nenhuma para a função deactivate.

Test Doubles e Refatoração

Usar um test double requer que saibamos de um certo nível de detalhe sobre a implementação do que estamos testando.

Nos cenários que testamos aqui foi preciso saber, por exemplo, que para um usuário ser considerado assinante ele deveria salvar o UUID que retornou da integração com o meio de pagamento. O teste fica vinculado à implementação.

Quando refatoramos o código é possível que o teste também precise ser refatorado. Então cabe ao desenvolvedor saber quando é necessário usar o test double ou quando podemos deixar para que a classe resolva o que precisa ser resolvido usando objetos reais.

Cuidado com o SUT

Quando executamos os testes estamos validando algum aspécto do SUT.

Os test doubles estão ai para nos ajudar a lidar com dependências de um ou mais componentes, isolar o objeto de teste, simplificar comportamentos e nos dar mais controle sobre a situação.

Às vezes se torna tentador criar um test double para substituir parte do SUT e essa é uma ideia ruim.

Se você tiver vontade de substituir o comportamento de determinada função da classe que está testando, por exemplo, veja como um indicativo de que aquele código possui uma complexidade alta e talvez faça sentido ser encapsulada em uma classe própria.

Bom, esse post acabou ficando maior do que eu imaginei, então vou parar por aqui.

Caso tenha ficado alguma dúvida pode deixar nos comentários que eu respondo assim que possível. E vou deixar aqui também alguns recursos que me ajudaram enquanto montava esse post:

Repositório com o código

Test Double - Martin Fowler

Test Doubles Swift - Matheus de Vasconcelos

Test Doubles - Pablo Rodrigo Darde

Don't Stub the System Under Test - Joe Ferris

PHP Testing Jargon - Laracasts

Até a próxima!

O que testar em um software?

Thalita Marra — Mon, 24 May 2021 21:18:03 +0000

Olá olá! Bora continuar o papo sobre testes?

No post anterior falei sobre o que são testes de software, quais as técnicas que podemos empregar na criação e execução dos mesmos e também quais suas classificações em relação à etapa do ciclo de vida do software.

Ou seja, já vimos o como e o quando testar, mas falta uma pergunta muito importante...

O que testar?

Sabemos que um teste de sistema, por exemplo, procura confirmar se o software desenvolvido está funcionando de acordo com os contratos definidos, mas o que valida se o contrato foi cumprido? Se eu informo um valor X e recebo Y de resposta? Se o tempo de execução até eu receber a resposta foi abaixo de N segundos? Existem vários aspectos do software que podem ser testados de acordo com as necessidades do projeto.

Dessa forma, podemos classificar os testes de acordo com seu foco (aquilo que pretendem validar):

• Teste de funcionalidade: tem como objetivo validar se as funções do sistema são executadas corretamente. Também checa se a aplicação envia resultados relevantes para o contexto do sistema, como por exemplo tratamentos de erros padronizados e suficientemente informativos.

• Teste de usabilidade: foca na experiência do usuário ao utilizar o sistema. Observa e analisa usuários reais utilizando o produto (que pode ser um site, um aplicativo, etc). É bastante comum o uso de protótipos para a execução desse teste.

• Teste de segurança: valida a proteção do sistema contra acessos não autorizados e invasões através da checagem de perfis de acesso, confirmação da codificação de dados quando necessário, etc. São executadas uma série de explorações no software buscando identificar e corrigir a maior quantidade possível de vulnerabilidades.

• Teste de portabilidade: atesta o funcionamento do sistema em diferentes plataformas e dispositivos nas quais o sistema foi proposto a funcionar. Por exemplo: valida se um site funciona em múltiplos navegadores, um aplicativo funciona em múltiplos sistemas operacionais, etc.

• Teste de desempenho: busca confirmar se o tempo de resposta de determinado software está dentro do esperado.

• Teste de stress: valida o comportamento do sistema em condições extremas para procurar e corrigir possíveis falhas e identificar melhorias de desempenho o quanto antes.

💡 Apesar de ser bem parecido com um teste de desempenho, o teste de stress leva o sistema ao limite, testando seu funcionamento em um ambiente com memória insuficiente, recursos compartilhados limitados, serviços indisponíveis, etc. O teste de desempenho já valida o sistema em um ambiente mais próximo da realidade.

Essas são os aspectos mais comuns a serem testados mas não são os únicos. Podemos testar coisas como concorrência, recuperabilidade do sistema, compatibilidade, por aí vai. Cada software pode ter alguma peculiaridade que precisa de garantia e para isso pode ser necessário testar coisas mais especificas.

Boas práticas

Por fim, mas não menos importante, vou deixar aqui algumas práticas que podem ajudar na definição, criação e execução dos testes:

• Idealmente, a pessoa que especifica os casos de testes não deve ser a mesma que participa da codificação. Se eu criei o login de um sistema e eu mesma vou testá-lo, é mais fácil me prender apenas ao que já presenciei enquanto codificava, ou seja, meus testes estarão enviesados.

• Faça uma boa seleção de cenários de teste. Considere o tempo disponível para a execução dos testes, a maturidade técnica dos envolvidos, a relevância das funcionalidades. E lembre-se que o que não está especificado não será validado.

• Quando necessário podemos explorar casos de testes além dos já definidos, aumentando ainda mais a cobertura do código.

• Não ignore cenários aparentemente inocentes.

• É bem possível encontrar falhas no sistema durante a execução dos testes. Quando isso acontecer, detalhe as falhas da melhor forma possível, assim facilita o trabalho de quem for corrigir e de quem for testar o sistema mais a frente.

• Inclusive, teste novamente os cenários com falhas depois das devidas correções!

• Ao reportar uma falha, busque padrões. Por exemplo: todos os produtos da categoria X apresentam erro quando adicionados ao carrinho de compras.

• Teste sempre os valores limites, há uma grande chance de erros estarem ali. Por exemplo: um sistema permite cadastro apenas de pessoas maiores de 18 anos e menores que 70 anos, então teste também as idades 16, 18, 70, 71... Testar os limites significa testar valores positivos e negativos, tamanhos de arquivos, etc.

• Confira se as informações retornadas pelo sistema estão coerentes, como mensagens de erros e sucesso, textos explicativos, etc.

• Por fim, pense como um usuário pensaria.

Então é isso, pessoal. Essas foram as minhas anotações das leituras sobre testes e do curso Teste de Software. Espero que ajude vocês também. Confesso que não fiz o curso todo porque queria estudar apenas a teoria inicial, mas super indico o material para quem ainda ficou meio perdido no assunto. E qualquer coisa pode deixar aqui nos comentários que vou respondendo assim que ver.

Até a próxima!

Como e quando testar um software?

Thalita Marra — Mon, 17 May 2021 12:32:41 +0000

Desenvolver um software não é uma tarefa lá muito simples. Envolve entender bem o que precisa ser feito, o objetivo da coisa e até os pontos sensíveis da ideia. Mas uma vez que o código da aplicação está pronto, acabou. Certo? Bem… Uma parte importantíssima do processo de desenvolvimento de uma aplicação é testá-la e garantir que tudo está funcionando conforme o esperado.

Para quem está codando se torna muito fácil enxergar apenas o “caminho feliz” das funcionalidades desenvolvidas e deixar passar alguns bugs despercebidos no caminho.

O teste de software serve justamente para tentar encontrar e resolver (até prevenir) as falhas que um programa possa apresentar para que, quando estiver disponível para o público, o comportamento do sistema seja o mais correto possível.

Tipos de testes

Os testes podem ser estáticos ou dinâmicos. Um teste estático é feito quando o sistema não está em execução. Esses testes vão desde uma análise visual do código buscando variáveis ou classes declaradas incorretamente até a análise do código por um software terceiro que procura por diversos code smells, por exemplo.

Um teste dinâmico é aquele que precisa que o sistema esteja em execução para que seja testado, onde se envia uma entrada e se espera determinada saída; são testes que validam o funcionamento do sistema.

Assim como separamos o teste de acordo com o estado da aplicação, também podemos separá-los de acordo à disponibilidade de acesso ao código.

Testes de caixa aberta (ou caixa branca) são aqueles feitos quando temos acesso ao código fonte e testes de caixa fechada (ou caixa preta) quando não possuímos acesso.

Por fim, os testes podem ser manuais ou automatizados. Os testes manuais são mais flexíveis e podem explorar mais casos além dos que foram planejados, porém são mais lentos e possuem um alto custo de execução.

Em contraposto os testes automatizados são mais rápidos e de mais fácil execução, possuindo um alto custo de criação e validando apenas os cenários especificados.

Testes por nível

Um software pode possuir diversos testes que irão envolver níveis diferentes de seus componentes, indo desde pequenas unidades de código até o sistema como um todo. Esses testes são desenvolvidos em função do estágio do ciclo de vida do software e são feitos para validar o desempenho e comportamento do software em diferentes estágios.

Antes de falar continuar, vamos repassar brevemente quais são os estágios do ciclo de vida de um software. De forma bem simples, temos:

Os seguintes testes validam diferentes níveis do sistema e são feitos de acordo com o estágio do ciclo de vida:

• Teste de unidade: procuram falhas em um único componente do sistema, funcionando independente do todo. Geralmente é o primeiro teste feito durante o desenvolvimento do sistema. São escritos por programadores e executados de forma automatizada.

• Teste de integração: busca validar a comunicação entre componentes do sistema em uma etapa mais intermediária do desenvolvimento, quando já existem componentes que interagem entre si. Também são escritos por programadores e executados de forma automatizada.

💡 Exemplo: classe Assinatura gere o plano de assinatura de um cliente e ela interage com a classe Boleto, que é responsável por emitir o boleto daquela assinatura.

• Teste de sistema: executa o sistema sob ponto de vista do usuário final, buscando falhas em relação aos objetivos originais. Pode ser executado através do navegador, um client rest ou qualquer plataforma que o usuário irá usar. Costuma ser feito por uma equipe de testes após a conclusão do desenvolvimento e auxiliado por um documento descrevendo todos os cenários de testes correspondentes aos requisitos do sistema.

• Teste de aceitação: bastante similar ao teste anterior, o teste de aceitação também executa o sistema sob a ótica do usuário final visando confirmar se o objetivo original foi atingido, mas ao invés de serem realizados por uma equipe especializada são planejados e executados por um grupo restrito de usuários finais do sistema. Esse teste que determina se o cliente aceita ou não o sistema que foi desenvolvido.

💡 Enquanto no teste de sistema uma equipe especializada valida se os contratos (requisitos) foram cumpridos, no teste de aceitação o cliente valida o desenvolvimento e confirma se aceita ou não o resultado apresentado.

• Teste de manutenção: também chamado de teste de regressão, procura garantir que as alterações em um código não afetam outros componentes que foram desenvolvidos em etapas anteriores do ciclo de vida. Após uma correção de bug ou alteração de um escopo, por exemplo, esses testes validam se todos os componentes que já estavam prontos permaneceram com o comportamento adequado. Podem envolver qualquer nível do sistema (unitário, interface, o sistema como um todo, etc).

Se juntarmos os testes com o ciclo de vida do produto temos algo assim:

Essa sequência é um compilado das minhas anotações de estudos sobre testes de software baseados em diversas leituras e, principalmente, no curso Teste de Software disponível na Udemy. E como ainda temos muito pano pra manga sobre esse assunto, vou deixar mais um pouquinho pra uma parte 2.

Nos vemos logo mais!