DEV Community: Wesley Egberto

Evolução do Switch no Java

Wesley Egberto — Tue, 09 Jan 2024 02:48:19 +0000

Do statement até expression e pattern matching.

O que cobriremos nesse post:

Switch statement
Switch expression (Java 14+)
Pattern matching (type pattern e record pattern)

Antes de iniciar, gostaria de fazer a seguinte distinção entre statement e expression:

Statement (declaração): qualquer código que é executado como uma únidade. Esse código pode executar um método, declarar algo (declaration statement), pode mudar o fluxo do programa (control flow statement), pode atribuir um valor (assignment statement), criar um objeto (object creation expression), criar uma lambda (lambda expression).
Expression (expressão): código que quando executado resultado em um único valor (expression statement).

No Java, os statements são executados de uma maneira top-bottom, conforme aparecem no seu programa.
Os statements de controle de fluxo são utilizado para esse comportamento ao efetuar a mudança da execução através de diferentes caminho no código.

Um dos recursos disponibilizado pelo Java para fazer controle de fluxo é o switch.

Um switch statement permite você executar diferentes caminhos no código de acordo com um teste lógico que é executado.
Diferente de um if-else statement, aqui podemos testar uma variável contra diferentes valores de uma vez e de forma mais clara.

Switch Statement

Até o Java 11, um switch statement era utilizado somente para controle de fluxo.

Um exemplo para entender a estrutura geral de um bloco switch:

String classe = "Mago";

switch (classe) { // 1
    case "Mago": // 2
        System.out.println("Gandalf"); // 3
        break; // 3
    case "Arqueiro": // 2
        System.out.println("Legolas");
        break;
    case "Guerreiro":
        System.out.println("Aragorn");
        break;
    default: // 4
        System.out.println("Classe inválida");
}

No código acima temos:

1: variável ou constante que será utilizada para testar os labels do bloco switch.
2: switch label, utiliza um valor para testar contra a variável, se for verdadeiro o seu bloco de código será executado.
3: block de código do case para execução, pode ou não ser terminada por um break.
4: break é utilizado para finalizar a execução do bloco do switch, caso não seja utilizado ocorrera um fall through.
5: case padrão que será executado caso todos os outros testes lógicos falhem.

A variável ou constante que será utilizada no switch precisa ser um dos seguintes tipos:

tipo primitivo: byte, short, char, int;
tipo referência: tipo enumerado (enum), String ou um tipo wrapper (Character, Byte, Short, Integer).

Fall Through

Caso o bloco de código do case em execução não tenha um break, os blocos de código dos próximos case serão executados (como se fossem verdadeiro) até que se encontre um break ou o bloco switch termine.

Exemplo:

int nota = 8;

switch (nota) {
    case 1:
    case 2:
    case 3:
    case 4:
    case 5:
        System.out.println("Tá péssimo, precisa melhorar!");
        break;
    case 6:
    case 7:
        System.out.println("Está bacana, mas há espaço para evolução!");
        break;
    case 8:
    case 9:
        System.out.println("Está excelente!");
        break;
    case 10:
        System.out.println("Está perfeito!");
        break;
    default:
        System.out.println("Nota inválida");
}

Acima, as notas entre 1 e 5 executarão o mesmo bloco de código.
Observe que os cases de 1 a 4 não tem um bloco de código explícito, é assumido um bloco vazio e apenas ocorre o fall through.

Switch Expression (Java 14+)

Até o Java 11, switch podia ser utilizado apenas como statement de controle de fluxo.

Se quiséssemos usar um switch para atribuir uma variável, tínhamos duas opções:

// atribuir uma varável local em cada case
String nota = "B";
String mensagem;

switch (nota) {
    case "A":
        mensagem = "Está perfeito!";
        break;
    case "B":
        mensagem = "Está muito bem!";
        break;
    case "C":
        mensagem = "Está razoável, podemos melhorar!";
        break;
    case "D":
        mensagem = "Está mal, vamos melhorar!";
        break;
    case "E":
        mensagem = "Está péssimo, bora pra cima!";
        break;
    case "F":
        mensagem = "Desisto!";
        break;
    default:
        mensagem = "Nota inválida!";
}

// ou usar um método para deixar mais claro e sucinto
public String getMensagemParaNota(String nota) {
    switch (nota) {
        case "A":
            return "Está perfeito!";
        case "B":
            return "Está muito bem!";
        case "C":
            return "Está razoável, podemos melhorar!";
        case "D":
            return "Está mal, vamos melhorar!";
        case "E":
            return "Está péssimo, bora pra cima!";
        case "F":
            return "Desisto!";
        default:
            return "Nota inválida!";
    }
}

// e usar
String mensagem = getMensagemParaNota("B");

Para os dois casos, é trabalhoso e neboluso devido à verbosidade do código.

Mas a partir do Java 12, foi proposta uma JEP para alterar o comportamento do switch para que possamos utilizá-lo como uma expression.
No Java 12 (JEP 325) e 13 (JEP 354), essa nova feature foi disponibilizada como preview para que a comunidade pudesse testar e dar o feedback.

E a partir do Java 14, a JEP 361 tornou Switch Expression uma feature padrão na linguagem.
Essa JEP introduziu as seguintes mudanças no switch:

1. Um block switch pode resultar em um valor, que pode ser utilizado em um assignment expression (ex.: String mensagem = switch (nota) { ... }).
2. Introduziu uma nova forma de switch label que utiliza uma arrow label (ex.: case 0 -> "Zero").
3. Passou a requerer exhaustiveness de cases em um Switch Expression (cobertura de todos os possíveis valores).

Switch Expression

Agora com Switch Expression, podemos atribuir variáveis ou retornar valores diretamente do switch.
Para isso, foi introduzido um statement com uma palavra-chave contextual yield para indicar o retorno de um valor do switch.
E não podemos misturar os blocos do switch label com break e yield pois, respectivamente, break é utilizado
somente em switch statement e yield é utilizado semente em switch expression.

Seguindo nosso exemplo anterior, podemos reescrever o switch:

String nota = "B";
String mensagem = switch (nota) { // 1
    case "A":
        yield "Está perfeito!"; // 2
    case "B":
        yield "Está muito bem!";
    case "C":
        yield "Está razoável, podemos melhorar!";
    case "D":
        yield "Está mal, vamos melhorar!";
    case "E":
        yield "Está péssimo, bora pra cima!";
    case "F":
        yield "Desisto!";
    default:
        System.err.println("Nota inválida: " + nota); // 3
        yield "Nota inválida!";
}; // 4

Algumas notas sobre o switch expression anterior:

1: atribuímos diretamente a variável com o switch, também poderíamos usar return ou passar um argumento para uma chamada de método.
2: usamos o yield para retornar o valor, caso não tenha um yield também ocorrerá o fall through para o próximo switch label.
3: podemos ter outros códigos no bloco da mesma forma.
4: precisa terminar com ponto-e-vírgula.

O uso do switch expression com yield é bacana nos casos que precisamos executar algumas operações antes de retornar o valor de fato.
Mas na maioria dos casos iremos retornar apenas um valor ou uma expression (ex.: resultado de um outro método), para simplificar ainda mais foi introduzido o arrow label.

O formato de switch label com case L: é chamado oficialmente de switch labeled statement group.

Tipo do Retorno

Importante destacar que um switch expression tem várias expressions de retorno, podemos ter diferentes tipos.

Arrow Labels

Um arrow label é formado por um switch label e uma arrow expression: case "A" ->.
Se o teste do switch label for verdadeiro, apenas a expression ou statement à direita da arrow que será executada, não ocorrerá o fall through como no caso devido
tradicional case "A" :.

A expression ou statement à direita tem a mesma construção de um lambda expression: um statement/expression de uma linha ou um bloco com chaves.

String nota = "B";
String mensagem = switch (nota) {
    case "A" -> "Está perfeito!"; // 1
    case "B" -> "Está muito bem!";
    case "C" -> "Está razoável, podemos melhorar!";
    case "D" -> "Está mal, vamos melhorar!";
    case "E" -> "Está péssimo, bora pra cima!";
    case "F" -> "Desisto!";
    default -> { // 2
        System.err.println("Nota inválida: " + nota);
        yield "Nota inválida!"; // 3
    } // 4
};

1: com arrow label podemos só por o valor de retorno ou chamada de método (nunca ocorrerá o fall through) e precisa terminar com ponto-e-vírgula.
2: caso precisemos executar várias instruções, podemos utilizar um bloco de código e retornar no final com yield.
3: com bloco de código sempre precisamos terminar com yield ou lançar exception, já que não ocorre o fall through.
4: o bloco de código não precisa terminar com ponto-e-vírgula.

Caso precisemos que múltiplos switch labels retornem o mesmo valor, precisamos combinar todos eles em um case só:

int nota = 8;

String mensagem = switch (nota) {
    // aqui todos os labels resultam no mesmo valor
    case 1, 2, 3, 4, 5 -> "Tá péssimo, precisa melhorar!";
    case 6, 7 -> "Está bacana, mas há espaço para evolução!";
    case 8, 9 -> "Está excelente!";
    case 10 -> "Está perfeito!";
    default -> "Nota inválida";
};

Também podemos usar o arrow label em um switch statement normalmente:

int nota = 8;

switch (nota) {
    case 1, 2, 3, 4, 5 -> {
        System.out.println("Tá péssimo, precisa melhorar!");
        if (nota > 4) {
            break; // ainda podemos utilizar para sair mais cedo do block
        }
        System.out.println("Agendar reunião com os pais...");
    }
    case 6, 7 -> System.out.println("Está bacana, mas há espaço para evolução!");
    case 8, 9 -> System.out.println("Está excelente!");
    case 10 -> System.out.println("Está perfeito!");
    default -> System.out.println("Nota inválida");
};

Exhaustiveness

Para utilizar um switch expression, precisamos fazer a exaustão dos possíveis valores do tipo da variável ou valor que estamos utilizado no switch.

Isso significa que precisamos ter um switch label para cada valor possível ou ter um default (na maioria dos casos onde usarmos os tipos primitivos ou uma String).
Caso o switch expression não trate todos os possíveis valores ocorrerá um erro de compilação (isso é legal porque nos ajuda a identificar facilmente os pontos de alteração por exemplo quando utilizamos um switch com enum em vários lugares).

enum Classe { GUERREIRO, MAGO, ARQUEIRO, BARDO };

Classe classe = Classe.MAGO;

String nome = switch (classe) {
    case GUERREIRO -> "Aragorn";
    case MAGO -> "Gandalf";
    case ARQUEIRO -> "Legolas";
    case BARDO -> "???";
    // caso falte algum valor para cobrir, precisamos usar o default
    // default -> "???"
}

Pattern Matching para Switch (Java 17+)

Da mesma forma que Switch Expression iniciou-se como uma feature em preview até ser incorporada por completa no Java.
Pattern Matching também foi introduzida como preview através de diferentes releases.

No Java 17, começou como preview e se manteve com esse status até o Java 20 (JEPs 406, 420, 427 e 433).
No Java 21, a JEP 441 lançou Pattern Matching for switch como padrão na linguagem.

Pattern Matching

Para entendermos o poder switch precisamos antes entender o que é pattern matching.

Pattern matching é uma poderosa técnica que existe desde a década de 1960 que é implementada em diversas linguagens de programação.
Um pattern matching nos permite fazer verificação do tipo e/ou da estrutura do dado de uma forma mais declarativa e orientada à dados.

O Java 17 suporta dois tipos de pattern matching:

Type pattern: onde verificamos o tipo da variável/valor; lançado no Java 16.
Record pattern: onde, além de aplicar type pattern, também podemos desconstruir um record para obter seus componentes; lançado no Java 21.

Pattern Matching com instanceof

Começaremos utilizando o operador instanceof para entender pattern matching.

A JEP 394 tornou a feature para suportar pattern matching no operador instanceof padrão no Java 16.

Utilizamos o operador instanceof para verificar se determinada variável é de um determinado tipo, e normalmente logo em seguida fazemos o cast explícito para esse tipo.
Pattern matching pode ajudar nesse cenário pois além de fazer o matching do tipo também é possível capturar o valor em uma nova variável já com o tipo desejado.

Ex.:

Object valor = "Texto recebido de algum lugar";

// Até o Java 16: forma de fazer a verificação do tipo até 
if (valor instanceof String) {
    String texto = (String) value;
    System.out.printlnt("Tamanho do texto: " + texto.length());
}

// A partir do Java 16: podemos usar pattern matching para capturar a variável no tipo desejado
if (valor instanceof String texto) {
    System.out.printlnt("Tamanho do texto: " + texto.length());
}

Observe que com pattern matching foi possível testar o tipo da variável valor e já criar uma nova variável fazendo o cast implícito para
o tipo.
E a variável local declarada no pattern tem o escopo somente do if.

Um type pattern é composto por dois componentes:

predicado (ou teste): que é utilizado para aplicar na variável alvo, no exemplo temos instanceof String.
variáveis pattern: variável utilizada para capturar o valor caso o predicado seja verdadeiro, no exemplo temos String texto.

O predicado do pattern matching é bem poderoso, podemos estender as condições utilizando a variável do pattern, que nesse momento já sabemos o tipo e capturamos em uma nova variável após o instanceof.
Mas sempre lembrando que precisamos utilizar o E lógico (&&) pois a nossa garantia está em cima do predicado do instanceof.

Ex.:

Object objeto = "Curto";

// podemos verificar junto a String capturada
if (objeto instanceof String texto && texto.length() < 10) {
    System.out.println("Texto curto");
}

Também podemos usar outros tipos quaisquer no type pattern, como record:

record Ponto(int x, int y) {}

Object objeto = new Ponto(10, 20);

if (objeto instanceof Ponto p && p.x() > 0) {
    int x = p.x();
    int y = p.y();

    System.out.println("Coordenadas do ponto: " + x + "," + y);
}

E para melhorar ainda mais, a partir do Java 21, a JEP 440 tornou padrão a feature de record pattern onde podemos aplicar pattern matching nos records e extrair seus componentes.

O exemplo anterior onde utilizamos apenas type pattern pode ser melhorado ainda mais ao utiliza record pattern:

record Ponto(int x, int y) {}

Object objeto = new Ponto(10, 20);

if (objeto instanceof Ponto(int x, var y) && x > 0) {
    System.out.println("Coordenadas do ponto: " + x + "," + y);
}

Com record pattern, podemos obter os componentes do record declarando variáveis seguindo sua estrutra.
No exemplo declaramos int x e var y (que será um inteiro).

Pattern Matching com switch

Agora voltando ao switch, tudo que vimos do uso de pattern matching podemos utilizar nos switch labels!
Graças a JEP 441 que tornou a feature padrão no Java 21! 🚀

Além disso, o switch também foi alterado para receber qualquer tipo, não somente aqueles básicos limitados. Isso torna os nossos switches muitos mais poderosos e menos verbosos.

E tem mais! Agora também podemos usar o null como switch label (null case), eliminando a necessidade de ficar fazendo verificação da variável antes de usar no switch.

Abaixo segue um exemplo completo onde utilizamos um switch com type pattern:

Object objeto = "Valor desconhecido";

String mensagem = switch (objeto) {
    case Integer i -> String.format("int %d", i); // 1
    case Long l -> String.format("long %d", l);
    case Double d -> String.format("double %f", d);
    case String s -> String.format("String %s", s);
    case null -> String.format("NULL"); // 2
    case int[] arr -> String.format("Array %s", arr);
    default -> objeto.toString(); // 3
};
System.out.println(mensagem);

Note que:

1: podemos aplicar type pattern da mesma forma para capturar o tipo.
2: podemos testar se é um valor nulo, simplificado e deixando explícito o tratamento, sem isso poderia ocorre um NPE.
3: por causa da exhaustiveness, precisamos de um case default para capturar todos os outros tipos existentes.

Guarded Case Label

No switch também podemos estender as condições da mesma forma com o if, mas aqui pode ser um refinamento do case que estamos deixando mais explícito.
Esse case label é chamado de guarded case label e a condição que estamos estendendo é chamado de guard.

Um exemplo para ilustrar:

Object resposta = "Sim";

String mensagem = switch (resposta) {
    case null -> "Ops, informe sua resposta!";
    case String s -> {
        if (s.equalsIgnoreCase("SIM"))
            yield "Vamos jogar!";
        if (s.equalsIgnoreCase("NAO"))
            yield "Que pena, volte amanhã!";
        yield "Não entendi, informe Sim/Nao";
    }
    default -> "Opção inválida, informe Sim/Nao";
};
System.out.println(mensagem);

O código acima, utilizando guarded case label fica mais simples e sucinto:

Object resposta = "Sim";

String mensagem = switch (resposta) {
    case null -> "Ops, informe sua resposta!";
    case String s when s.equalsIgnoreCase("SIM") -> "Vamos jogar!";
    case String s when s.equalsIgnoreCase("NAO") -> "Que pena, volte amanhã!";
    default -> "Opção inválida, informe Sim/Nao";
};
System.out.println(mensagem);

Utilizamos a palavra-chave contextual when para indicar a guard do nosso case.

Dominância

E por último, um ponto importante sobre os cases do switch é que devemos respeitar a hierarquia de tipos pois um case pode ter dominância sobre outro ao ser um super tipo dele.
É a mesma coisa que acontece com a captura de exceções em um try-catch com muitos catch.

Exemplo:

Number valor = 10L;

String mensagem = switch (valor) {
    case null -> "NULL";
    case Byte b -> String.format("byte %b", b);
    // ao 
    // case Number n -> String.format("Number %s", n); // 1
    // Erro: this case label is dominated by a preceding case label
    case Integer i -> String.format("int %d", i);
    case Long l -> String.format("long %d", l);
    case Double d -> String.format("double %f", d);
    case Number n -> String.format("Number %s", n); // 2
};

1: deixar o Number fará com que esse case demine todos os próximos cases porque é um supertipo de todos ele.
2: precisamos deixar os tipos mais genéricos da árvore no final, note também que não precisamos de um default já que temos o tipo mais genérico possível.

Com tudo isso em mente, também podemos misturar type pattern com constantes, mas sempre respeitando os casos de dominância.

Integer valor = 42;

String mensagem = switch (valor) {
    case null -> "NULL";
    case 0 -> "Zerado";
    // aqui tratamos o 42 especial para não cair no próximo case
    case 42 -> "Resposta do Universo";
    case Integer i when i > 0 -> "Valor positivo";
    case Integer i -> "Valor negativo";
};
System.out.println(mensagem);

Exhaustiveness (Java 17+)

Com a JEP 441, o compilador somente vai requerer exhaustiveness para os seguintes casos (por motivo de compatibilidade):

se o switch utiliza qualquer pattern;
se existe um null label;
se a expressão de seleção não é um dos tipos "legados" (char, byte, short, int, Character, Byte, Short, Integer, String ou um enum.

Conclusão

Toda essas novas features trazidas na linguagem e incorporada no switch está tornando a linguagem cada vez mais poderosa, menos verbosa e mais simples de se utilizar e entender.

A tendência é que novas formas de pattern matching entrem na linguagem (como desconstrução de qualquer classe).

Com isso terminamos a nossa longa jornada através da evolução do switch na linguagem Java.

Neste repositório do Github tenho alguns exemplos diferentes de switch com pattern matching onde busquei explorar as novas capacidades trazidas pela JEP.
Tenho também diversas outros exemplos mostrando outras features que foram lançadas no Java.

Neovim - Workflow para Java, C# e JS/TypeScript (Atualização com Neovim 0.8 e LSP)

Wesley Egberto — Sun, 01 Jan 2023 17:32:55 +0000

Em 2020 escrevi um post sobre workflow no Neovim 0.4.

Aqui atualizo aquele post com o meu setup onde utilizo as novas features do Neovim e do LSP.

Print do meu PDE (Personal Development Environment):

Introdução

Neovim é um projeto que de acordo com o repositório no Github, busca refatorar agressivamente o Vim para que seja possível:

Simplificar manutenção e encorajar contribuição;
Dividir o trabalho entre múltiplos desenvolvedores;
Habilitar UI avançada sem modificações no core;
Maximizar extensibilidade.

A maior vantagem que percebi foi a comunidade provendo diversas interfaces e extensões que facilitam a transição de uma IDE para o Neovim.

Para introdução e motivação completa acesse a Wiki no Github.

A partir do Neovim 0.6, com o lançamento da engine de LSP, ficou muito mais fácil e amigável configurar o Neovim para usar com as principais linguagens utilizadas no mercado.

Instalação

Para instalação basta seguir os passos descritos aqui onde é disponibilizados os pacotes e comandos para instalação em diversos SOs.

Todos os comandos do Vim funcionam normalmente no Neovim visto que é um fork da versão Vim 7.4.160 e que vem sendo atualizado constantemente.

Plugins

Alguns plugins que uso:

PAQ: gerenciador de plugins, permite instalar/atualizar os plugins através da referência do github (ex.: paq {'savq/paq-nvim'}), vale a pena adicionar uma referência dele mesmo para permitir atualizações automáticas. Também existe o Packer que é bem utilizado.
Telescope: plugin que permite fazer fuzzy find de qualquer coisa (arquivos, arquivos git, documentos LSP, comandos, helptags, etc), possui diversas extensões que permite adicionar novas funcionalidades (eu utilizo algumas onde disponibilizo na configuração).
Galaxyline: plugin para exibir algumas informações no rodapé do painel (como branch, linguagem, tamanho do arquivo, etc).
Vim-numbertoggle: plugin para facilitar a navegação relativa com j e k.
Hop: plugin para facilitar e acelerar a navegação no arquivo similar ao EasyMotion mas com algumas melhorias.
vim-visual-multi: plugin para habilitar multiplos cursores igual ao Ctrl+D do VS Code.
LSP:
- nvim-lspconfig, mason.nvim e mason-lspconfig: plugin para facilitar as configurações das engines LSP para utilizar nas linguagens de programação desejadas.
- lspkind-nvim: plugin para adicionar ícones nas entidades de LSP (classe, método, snippet, etc) igual ao VS Code.
which-key: plugin que permite configurar um menu com os comandos disponíveis conforme digitamos nossas keybindings, facilita na memorização das keybindings conforme vamos utilizando.

Workflow

Com o LSP do Neovim e os plugins de autoconfiguração, todas as linguagens que utilizado podem ser configurada e customizada facilmente.

Com o LSP é possível configurar os atalhos para todas as ações disponíveis nos LSP (go to definition, go to implementation, find references, find type, action, etc), assim não será preciso nenhum outro plugin para configurar essas ações (como era necessário no Coc.nvim).

Para facilitar a experiência no Neovim e trazer aquele feeling de IDE utilizo as extensões abaixo:

nvim-tree.lua: plugin com explorador lateral para permitir navegar na estrutura de diretório do projeto. O plugin nvim-web-devicons adiciona os ícones dos principais tipos de arquivos na visualização do explorador.
autocomplete e snippets:
- utiliza a engine nvim-cmp para configurar os snippets nos projetos, ela permite ser extendida com snippets de outros plugins e das engines de LSP, também é possível configurar nossas próprias snippets seguindo a configuração do VS Code.
- nvim-cmp: engine de autocomplete;
- cmp-nvim-lsp: integração com LSP;
- LuaSnip: engine de snippets, suporta o formato do VS Code (é possível copiar os arquivos de snippets do VS Code e utiliza diretamente no Neovim);
- cmp-luasnip: integração do LuaSnip com nvim-cmp;
- friendly-snippets: coleção de snippets de várias linguagens e frameworks.
git:
- utilizo alguns plugins para facilitar a integração com o Git (símbolos no arquivo para informar se houve adição/remoção/alteração na linha, git blame na linha, diff view e conflitos);
- plugins:
- vim-fugitive: disponibiliza os comandos Git para executar direto do Neovim;
- vim-gitgutter: símbolos no arquivo com o status do arquivo no Git;
- nvim-blame-line: informações do Git blame direto na linha do arquivo;
- diffview.nvim: diff view direto no Neovim;
- git-conflict.nvim: marca os conflitos do arquivo.

Para facilitar minha vida nas tarefas rápidas que faço pelo terminal (como docker, git, npm, etc) utilizo o vim-floaterm que permite executar diversas tarefas através de popups.

Abaixo segue as combinações de plugins que utilizo para cada linguagem de forma que tenha sempre autocomplete, snippets, code checking e builds:

Java: mason.nvim já configura todas as ferramentas necessárias, é preciso apenas se atentar na versão da linguagem que é utilizada no JDT do Eclipse (atualmente requer o JDK 17). Também é possível utilizar o plugin nvim-jdtls que possibilita configuração completa do JDT (diferentes versões da JDK, XML de formatação, DAP para debug e testes). Aqui tem a configuração completa do JDT que estou utilizando no momento.
Javascript/TypeScript: mason.nvim já configura todas as ferramentas necessárias, também é possível utilizar o plugin typescript.nvim que configura o LSP e provê fatures adicionais (como decompilação).
C#: mason.nvim já configura as ferramentas necessárias, mas também é possível utilizar o plugin Omnisharp-vim que permite uma maior customização e integração com Omnisharp.

Dotfiles

Além desses existem diversos outros plugins para facilitar navegação, edição e suporte de linguagens e highlight de sintaxes.

Para ver todos os plugins e configurações que utilizo acesse meu Dotfiles no Github.

Angular - Testes de Componentes

Wesley Egberto — Sun, 20 Mar 2022 00:26:34 +0000

No post anterior falamos sobre os testes de Pipes e Services.

Outros posts da série:

Neste post, iniciaremos nossos testes em componentes do Angular.

Introdução

Diretamente da documentação do Angular, um componente combina um template HTML e uma classe TypeScript.
E para testar este componente adequadamente, deveríamos testar se combinação do template HTML e sua classe funcionam corretamente.

Esses testes requerem que criemos o elemento do componente na árvore DOM do browser e realizássemos as interações necessárias para cobrir todo o seu comportamento.

Para isso, o Angular nos disponibiliza a classe TestBed que facilita a configuração da base do Angular necessária para renderização do componente e todas as dependências do componente.

Mas, em alguns casos, realizar o teste unitário da classe do componente, sem a renderização em um DOM, pode validar todo o comportamento necessário.

Teste Unitário da Classe de Componente

A classe do componente, normalmente, contém todo o estado e comportamento do seu componente, caso o seu HTML esteja mantem estado e/ou executando ações - como em <button (click)="form.reset()">Limpar</button> - recomendo extrair para a classe de componente.
Ao realizar os testes unitários do estado e ações da classe do componente, estamos, praticamente, testando completamente o componente.

A situação pode ser bem mais complicada nos casos em que o componente utiliza outros componentes para realizar seus objetivos, nestes casos é recomendado realizar completo do componente visando interação com esses componentes.

Testando Componente

Testando Data Binding

Neste exemplo, iremos testar um componente cujo objetivo é exibir uma interface com um botão para ligar e desligar alguma coisa.
Nele simplesmente exibimos um botão que nos permite ligar ou desligar. Quando desligado, o botão fica vermelho e exibe o texto Turn on e, quando ligado, o botão fica verde e exibe o texto Turn off.

Código do Componente

Abaixo seguem os arquivos do componentes.

Arquivo simple-switch-button.component.html:

<button (click)="toggle()" [style.backgroundColor]="buttonColor">{{ buttonLabel }}</button>

Arquivo simple-switch-button.component.ts:

import { Component } from '@angular/core';
import { ButtonState } from './button-state';

@Component({
  selector: 'app-simple-switch-button',
  templateUrl: './simple-switch-button.component.html'
})
export class SimpleSwitchButtonComponent {
  state: ButtonState = ButtonState.OFF;

  constructor() { }

  get buttonLabel() {
    return this.state === ButtonState.ON ? 'Turn off' : 'Turn on';
  }

  get buttonColor() {
    return this.state === ButtonState.ON ? 'green' : 'red';
  }

  toggle() {
    this.state = this.state === ButtonState.ON ? ButtonState.OFF : ButtonState.ON;
  }
}

Teste da Classe do Componente

Caso precisássemos testar apenas a classe de componente, ao julgar que a cobertura do estado e comportamento é o bastante para garantir a funcionalidade, podemos escrever os testes igual faríamos em um teste de um service sem dependências.

Arquivo simple-switch-button.component-class.spec.ts:

import { SimpleSwitchButtonComponent } from './simple-switch-button.component';
import { ButtonState } from './button-state';

describe('SimpleSwitchButtonComponent (class-only)', () => {
  let component: SimpleSwitchButtonComponent;

  beforeEach(() => {
    // antes de cada teste criamos o componente para ter seu estado sem interferência de outros testes
    component = new SimpleSwitchButtonComponent();
  });

  it('should start in off state', () => {
    // testamos o estado inicial do componente
    expect(component.state).toBe(ButtonState.OFF);
  });

  // aqui testamos o comportamento de mudar do estado OFF para ON
  it('should turn on when the off state is toggled', () => {
    component.state = ButtonState.OFF;

    component.toggle();

    expect(component.state).toBe(ButtonState.ON);
  });

  // aqui testamos o comportamento de mudar do estado ON para OFF
  it('should turn off when the on state is toggled', () => {
    component.state = ButtonState.ON;

    component.toggle();

    expect(component.state).toBe(ButtonState.OFF);
  });

  // aqui testamos se o texto do botão é exibido corretamente de acordo com o estado
  it('should display the correct label for each state', () => {
    component.state = ButtonState.OFF;
    expect(component.buttonLabel).toBe('Turn on');

    component.state = ButtonState.ON;
    expect(component.buttonLabel).toBe('Turn off');
  });

  // aqui testamos se a cor do botão é exibida corretamente de acordo com o estado
  it('should display the correct color for each state', () => {
    component.state = ButtonState.OFF;
    expect(component.buttonColor).toBe('red');

    component.state = ButtonState.ON;
    expect(component.buttonColor).toBe('green');
  });
});

Teste do Binding do DOM

Em alguns casos, testar somente a classe do componente pode não ser o bastante devido a necessidade de teste dos elementos em si da tela.

Ao testar o componente no DOM podemos fazer um teste mais completo dele, vamos conseguir validar:

Renderização dos elementos:
- o texto é exibido corretamente
- as formações estão sendo aplicadas
- as cores esperadas estão sendo aplicadas
Interações do usuário:
- o botão clicado está chamando o método correto
- a mensagem de feedback está sendo exibida
- as interações esperadas estão ocorrendo
Interações com componentes filhos:
- a interação do usuário está sendo refletida nos outros componentes

Configuração do Módulo de Teste

Para testar o comportamento do componente no DOM, podemos fazer um configuração completa do teste do componente utilizando a classe TestBed.

A classe TestBed configura o módulo de testes com as configurações e importações básicas necessárias para rodar o teste (como importar o módulo BrowserModule).

// configura o módulo de teste com o nosso componente
TestBed.configureTestingModule({
    declarations: [ SimpleSwitchButtonComponent ],
    // caso nosso componente tenha utilize um service como dependência
    providers: [
      { provide: MyService, useValue: MyMockedService }
    ]
  })
  // compila o componente (html, ts e css)
  .compileComponents();

// cria o componente (o TestBed já adiciona no DOM do nosso test-runner)
const fixture: ComponentFixture<SimpleSwitchButtonComponent> = TestBed.createComponent(SimpleSwitchButtonComponent);
// obtém a instância do componente
const component: SimpleSwitchButtonComponent = fixture.componentInstance;
// dispara o ciclo de vida do componente no Angular
fixture.detectChanges();

A classe instância de ComponentFixture que o TestBed nos retorna é um utilitário para facilitar a interação com o componente criado e todos os seus elementos.

Angular provê duas formas de acessar o elemento do componente:

const deElem: DebugElement = fixture.debugElement
const naElem: HTMLElement = fixture.nativeElement

nativeElement

O atributo fixture.nativeElement (atalho para fixture.debugElement.nativeElement) depende do ambiente em que está rodando (se é um runner com suporte a API HTML ou não).
Ele somente é definido nos casos em que os testes estão rodando em uma plataforma browser, caso esteja rodando fora dele não será definido visto que não haverá renderização completa (ex.: web worker).

Podemos utilizar a API padrão do HTML no nativeElement:

it('should have <p> with "banner works!"', () => {
  const bannerElement: HTMLElement = fixture.nativeElement;
  const p = bannerElement.querySelector('p')!;
  expect(p.textContent).toEqual('banner works!');
});

debugElement

O Angular fornece a classe DebugElement como abstração do elemento para poder suportar todas as plataformas de forma segura.
Angular cria a árvore do DebugElement que encapsula os elementos nativos da plataforma que está rodando.

it('should have <p> with "banner works!"', () => {
  const p = fixture.debugElement.query(By.css('p'));
  expect(p.nativeElement.textContent).toEqual('banner works!');
});

A classe utilitária By nos ajuda efetuar buscas no métodos de busca do DebugElement que suporte todas as plataformas (browser, server side rendering, etc) e sempre retorna um DebugElement.

Importamos a partir com import { By } from '@angular/platform-browser';.

Data Binding

Note que no teste estamos executando fixture.detectChanges() para que o Angular execute o ciclo de vida (e assim efetue o data binding).
Em alguns casos sempre vamos precisar utilizar o data binding nos testes, então o Angular disponibiliza uma forma de deixar a detecção de mudanças automática para que não precisemos ficar sempre chamando.

O service ComponentFixtureAutoDetect vai sempre disparar o data binding sempre que alguma atividade assíncrona finalizar (como resolução de promise, timers, eventos do DOM, criação do componente).
Para os casos que alterarmos o componente diretamente no teste, ainda vamos precisar chamar o detectChanges.

TestBed.configureTestingModule({
  declarations: [ BannerComponent ],
  providers: [
    { provide: ComponentFixtureAutoDetect, useValue: true }
  ]
});

Testando o Estado e Interações com DOM

// Para Angular 10+, recomenda utilizar a função `waitForAsync` que tem o mesmo comportamento.
import { async, ComponentFixture, TestBed } from '@angular/core/testing';
import { By } from '@angular/platform-browser';
import { DebugElement } from '@angular/core';

import { SimpleSwitchButtonComponent } from './simple-switch-button.component';
import { ButtonState } from './button-state';

describe('SimpleSwitchButtonComponent', () => {
  // criamos as variáveis com os elementos que vamos interagir nos testes
  let component: SimpleSwitchButtonComponent;
  let fixture: ComponentFixture<SimpleSwitchButtonComponent>;

  // utilizamos a função `async` (ou `waitForAsync` no Angular 10+) para aguardar a construção do módulo de teste
  beforeEach(async(() => {
    TestBed.configureTestingModule({
        declarations: [ SimpleSwitchButtonComponent ]
      })
      .compileComponents();

    // criamos o componente que vamos testar
    fixture = TestBed.createComponent(SimpleSwitchButtonComponent);
    component = fixture.componentInstance;
    // já iniciamos o ciclo de vida do Angular
    fixture.detectChanges();
  }));

  // testamos se o componente pode ser construído
  it('should create the component', () => {
    expect(component).toBeTruthy();
  });

  // testamos o estado inicial do componente
  it('should start displaying a button with text `Turn on` and with red color', () => {
    // usamos `By.css` para pesquisar um elemento do componente
    const button: DebugElement = fixture.debugElement.query(By.css('button'));
    // testamos se o botão foi criado
    expect(button).toBeTruthy();

    // testamos o texto do botão (diferentes formas de acessar o texto do elemento)
    expect(button.nativeElement.innerText).toBe('Turn on');
    expect(button.nativeElement.textContent).toBe('Turn on');
    expect(button.nativeNode.innerText).toBe('Turn on');

    // testamos o estilo do botão (diferentes formas de verificar, sempre prefira acessar através de DebugElement)
    expect(button.styles.backgroundColor).toBe('red');
    expect(button.nativeElement.style.backgroundColor).toBe('red');
  });

  // testamos o comportamento do click no botão quando o estado é OFF
  it('should display text `Turn on` and be red when state is off', () => {
    component.state = ButtonState.OFF;

    const button: DebugElement = fixture.debugElement.query(By.css('button'));
    fixture.detectChanges();

    expect(button.nativeElement.innerText).toBe('Turn on');
    expect(button.styles.backgroundColor).toBe('red');
  });

  // testamos o comportamento do click no botão quando o estado é ON
  it('should display text `Turn off` and be green when state is on', () => {
    component.state = ButtonState.ON;

    const button: DebugElement = fixture.debugElement.query(By.css('button'));
    fixture.detectChanges();

    expect(button.nativeElement.innerText).toBe('Turn off');
    expect(button.styles.backgroundColor).toBe('green');
  });

  // testamos o comportamento do click duas vezes (toggle)
  it('should change the button text and color when clicked', () => {
    component.state = ButtonState.OFF;
    const button: DebugElement = fixture.debugElement.query(By.css('button'));

    button.triggerEventHandler('click', null);
    fixture.detectChanges();

    expect(button.nativeElement.innerText).toBe('Turn off');
    expect(button.styles.backgroundColor).toBe('green');

    button.triggerEventHandler('click', null);
    fixture.detectChanges();

    expect(button.nativeElement.innerText).toBe('Turn on');
    expect(button.styles.backgroundColor).toBe('red');
  });
});

Karma e o DOM

Abaixo segue um print do que é exibido no Karma após rodar os testes.
Note que o o botão está renderizado no meio do relatório porque o Karma é o nosso test runner, então é o responsável pela criação e renderização do DOM.

Testando Formulário

O Angular disponibiliza duas formas de criar formulário: Reactive Form e Template Driven.

Reactive Form: forma que facilita a escrita dos testes;
Template Driven: os testes são um pouco mais verbosos de se escrever por precisar ficar obtendo instância de cada campo.

Neste exemplo, testaremos um formulário template-driven que envia contato para uma API qualquer.
O formulário de contato envia uma mensagem para a API, se tudo ocorrer bem exibe uma mensagem de sucesso em verde e se der algum erro exibe mensagem de erro em vermelho.

Código do Componente e do Service

Arquivo contact-form.component.html:

<form #contactForm="ngForm" (ngSubmit)="sendContact()">
  <fieldset>
    <div class="field">
      <label>Full name</label>
      <input type="text" name="name" [(ngModel)]="contact.name" required pattern="\w+ \w+">
    </div>

    <div class="field">
      <label>E-mail</label>
      <input type="email" name="email" [(ngModel)]="contact.email"
        required pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,4}$"
      />
    </div>

    <div class="field">
      <label>Subject</label>
      <input type="text" name="subject" [(ngModel)]="contact.subject" required>
    </div>

    <div class="field">
      <label>Message</label>
      <textarea name="message" [(ngModel)]="contact.message" required></textarea>
    </div>

    <div>
      <button type="submit" [disabled]="!contactForm.form.valid">Send</button>
    </div>

    <div *ngIf="hasMessageToDisplay">
      <p class="feedback-message" [class.success]="!errorOccurred" [class.error]="errorOccurred">{{ message }}</p>
    </div>
  </fieldset>
</form>

Arquivo contact-form.component.css:

label { display: block; }

input, textarea { min-width: 250px; }

.feedback-message {
  font-size: 1.1em;
  font-weight: bold;
}

.feedback-message.success { color: green; }

.feedback-message.error { color: red; }

Arquivo contact-form.component.ts:

import { Component } from '@angular/core';

import { ContactService } from './contact.service';

@Component({
  selector: 'app-contact-form',
  templateUrl: './contact-form.component.html',
  styleUrls: ['./contact-form.component.css']
})
export class ContactFormComponent {
  contact = {
    name: '',
    email: '',
    subject: '',
    message: ''
  };
  errorOccurred: boolean = false;
  message: string = null;

  constructor(private _contactService: ContactService) { }

  get hasMessageToDisplay(): boolean {
    return !!this.message;
  }

  private showSuccessMessage(message: string) {
    this.errorOccurred = false;
    this.message = message;
  }

  private showErrorMessage(message: string) {
    this.errorOccurred = true;
    this.message = message;
  }

  sendContact() {
    this._contactService.sendContact(this.contact)
      .subscribe(
        result => this.showSuccessMessage('Your message has been sent!'),
        err => this.showErrorMessage('An error occurred while sending your message.')
      );
  }
}

Arquivo contact.service.ts:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable, throwError } from 'rxjs';
import { map } from 'rxjs/operators';

@Injectable()
export class ContactService {
  constructor(private _http: HttpClient) { }

  sendContact(contact: any): Observable<any> {
    return this._http
      .post('https://httpbin.org/post', contact)
      .pipe(map(result => 'OK'));
  }
}

Testando o Formulário

Arquivo de teste contact-form.component.spec.ts:

import { async, ComponentFixture, ComponentFixtureAutoDetect, TestBed } from '@angular/core/testing';
import { DebugElement } from '@angular/core';
import { By } from '@angular/platform-browser';
import { FormsModule } from '@angular/forms';
import { of, throwError } from 'rxjs';

import { ContactFormComponent } from './contact-form.component';
import { ContactService } from './contact.service';

describe('ContactFormComponent', () => {
  let mockedService: jasmine.SpyObj<ContactService>;

  let fixture: ComponentFixture<ContactFormComponent>;
  let component: ContactFormComponent;

  let inputName: DebugElement;
  let inputEmail: DebugElement;
  let inputSubject: DebugElement;
  let inputMessage: DebugElement;
  let buttonSubmit: DebugElement;

  beforeEach(async(() => {
    mockedService = jasmine.createSpyObj('ContactService', ['sendContact']);

    TestBed.configureTestingModule({
        imports: [ FormsModule ],
        declarations: [ ContactFormComponent ],
        providers: [
          // usamos o auto detect para facilitar algumas interações com formulário e RxJS
          { provide: ComponentFixtureAutoDetect, useValue: true },
          { provide: ContactService, useValue: mockedService }
        ]
      })
      .compileComponents();

    fixture = TestBed.createComponent(ContactFormComponent);
    component = fixture.componentInstance;

    // obtemos as instâncias dos inputs que iremos manipular
    inputName = fixture.debugElement.query(By.css('input[name=name]'));
    inputEmail = fixture.debugElement.query(By.css('input[name=email]'));
    inputSubject = fixture.debugElement.query(By.css('input[name=subject]'));
    inputMessage = fixture.debugElement.query(By.css('textarea[name=message]'));
    buttonSubmit = fixture.debugElement.query(By.css('button[type=submit]'));
  }));

  // função auxiliar para preencher o form com dados válidos
  function fillValidContactInfo() {
    // define o texto do input
    inputName.nativeElement.value = 'John Doe';
    // dispara o evento de input simulando o usuário
    inputName.nativeElement.dispatchEvent(new Event('input'));

    inputEmail.nativeElement.value = 'john.doe@server.com';
    inputEmail.nativeElement.dispatchEvent(new Event('input'));

    inputSubject.nativeElement.value = 'Test subject';
    inputSubject.nativeElement.dispatchEvent(new Event('input'));

    inputMessage.nativeElement.value = 'Test message';
    inputMessage.nativeElement.dispatchEvent(new Event('input'));
  }

  // testa se todos os campos foram criados corretamente
  it('should create the component with contact fields visible and disabled button', () => {
    expect(component).toBeTruthy();

    expect(inputName).toBeTruthy();
    expect(inputEmail).toBeTruthy();
    expect(inputSubject).toBeTruthy();
    expect(inputMessage).toBeTruthy();

    expect(buttonSubmit).toBeTruthy();
    // verificarmos se o botão inicia desabilitado (atributo `DebugElement.properties` com os atributos do elemento)
    expect(buttonSubmit.properties.disabled).toBe(true);
  });

  // testa se o botão será habilitado caso preencha o form com dados válidos
  it('should accept valid inputs and bind to model', () => {
    fillValidContactInfo();

    // verificamos se os inputs estão linkados corretamente na model esperada do componente
    expect(component.contact.name).toBe('John Doe');
    expect(component.contact.email).toBe('john.doe@server.com');
    expect(component.contact.subject).toBe('Test subject');
    expect(component.contact.message).toBe('Test message');

    // verificamos se o botão foi habilitado para o usuário
    expect(buttonSubmit.properties.disabled).toBe(false);
  });

  // testa se o botão será desabilitado caso preencha um e-mail inválido
  it('should not allow sent e-mail', () => {
    fillValidContactInfo();

    // atualizamos apenas o campo que queremos invalidar
    inputEmail.nativeElement.value = 'invalid.mail@mailcom';
    inputEmail.nativeElement.dispatchEvent(new Event('input'));

    expect(buttonSubmit.properties.disabled).toBe(true);
  });

  // testa se permite enviar o formulário após preencher com dados válidos
  it('should allow send contact with valid info', () => {
    // aqui espiamos o método `sendContact` do form para ver se ele foi chamado
    // e também configuramos para seguir sua implementação real (já que queremos ver se tudo foi chamado corretamente)
    spyOn(component, 'sendContact').and.callThrough();
    // aqui mockamos o método `sendContact` da nossa service para retornar um OK
    mockedService.sendContact.and.returnValue(of('OK'));

    fillValidContactInfo();

    // recuperarmos o formulário para disparar o evento de submit
    const form = fixture.debugElement.query(By.css('form'));
    form.triggerEventHandler('submit', {});
    // dispara o ciclo de vida para a tela refletir o resultado da chamada
    fixture.detectChanges();

    // verificamos se o método do componente e da service foram chamados
    expect(component.sendContact).toHaveBeenCalled();
    // além de verificar se foi chamado, também vale a pena testar se a model foi passada corretamente (igual fizemos na service no post anterior)
    expect(mockedService.sendContact).toHaveBeenCalled();

    // recuperamos o elemento de mensagem de feedback para verificar se está exibindo o caso de sucesso
    const message = fixture.debugElement.query(By.css('p.feedback-message'));
    expect(message).toBeTruthy();
    expect(message.nativeElement.textContent).toBe('Your message has been sent!');
    // verificamos se a classe CSS foi aplicado corretamente
    expect(message.classes['success']).toBe(true);
  });

  // testa se exibe o feedback da mensagem de erro
  it('should show error when it is thrown', () => {
    // aqui repetimos o spy para chamar o método da service
    spyOn(component, 'sendContact').and.callThrough();
    // mockamos um retorno de erro
    mockedService.sendContact.and.returnValue(throwError('Error for testing'));

    fillValidContactInfo();

    const form = fixture.debugElement.query(By.css('form'));
    form.triggerEventHandler('submit', {});
    fixture.detectChanges();

    expect(component.sendContact).toHaveBeenCalled();
    expect(mockedService.sendContact).toHaveBeenCalled();

    // recuperamos o elemento de mensagem para verificar se a mensagem de erro foi exibida
    const message = fixture.debugElement.query(By.css('p.feedback-message'));
    expect(message).toBeTruthy();
    expect(message.nativeElement.textContent).toBe('An error occurred while sending your message.');
    expect(message.classes['error']).toBe(true);
  });
});

No próximo post iremos testar componentes com @Input e @Output, e a interação entre diferentes componentes.

Github Actions - Introdução com Java

Wesley Egberto — Sat, 02 Oct 2021 20:37:05 +0000

Github Actions nos permite automatizar, customizar e executar workflows do desenvolvimento de software diretamente no repositório do projeto.

Podemos:

rodar o build continuamente
executar testes automatizados a cada push
executar processo de CI completo
executar processo de CD para diversas clouds e ambientes

O Github Actions possui uma ampla biblioteca de Actions que nos permites executar diversos tipos de ações (desde simples build da aplicação até o build da sua imagem Docker e deploy no seu cluster Kubernetes na AWS).

Os jobs do Github Actions são orientados à eventos, isso significa que você pode configurar a execução de determinado job a partir de uma determinada ação (push, PR, merge) no seu repositório.

O Github Actions possui uma camada free que nos disponibiliza um tempo de execução mensal dos jobs e um período de retenção dos logs de forma limitada, detalhes podem ser acessados aqui.
No plano Enterprise do Github, é possível adicionar processo de aprovação em ambientes no workflow a fim de limitar quem pode fazer o quê em determinados ambientes.

Componentes

Workflows

Um workflow é um procedimento declarado e automatizado que adicionamos no repositório através de um arquivo YAML.
Um workflow é composto de um ou mais jobs que podem ser agendados ou iniciados por um ou mais eventos.

Events

Um evento é uma ação específica que pode disparar um ou mais jobs dos workflows declarados no repositório.
Essa ação pode ser um push, PR ou merge efetuado no repositório.

Na documentação do Github, tem a lista de ações disponíveis que podemos utilizar para disparar um workflow.

Job

Um job é composto por um ou mais steps que executam em um mesmo runner de forma sequencial a partir de determinado evento.
Abaixo segue o diagrama mostrando a estrutura do job:

Um workflow com mais de um job pode rodá-los em paralelos ou de forma sequencial, caso seja configurado.

Actions

Action são comandos isolados que são combinados em steps para criar um job.
Uma Action é o menor nível portável de um workflow, podemos criar e reutilizar Actions através de nossos repositórios ou compartilhar com a comunidade.
Um Action sempre estará dentro de um step para poder ser executado no workflow.

Runner

Um runner é um server que tem a runner application do Github Actions instalada.
Podemos utilizar um runner hospedado pelo Github ou em nossa própria infraestrutura.
Um runner busca jobs disponíveis, roda-os e reporta o progresso, logs e resultados para o repositório no Github.

Estrutura do Workflow

O workflow é declarado em um arquivo YAML com um esquema de declaração do Github Actions para definir os eventos, jobs e seus steps.
Esse arquivo YAML fica armazenado junto à aplicação no repositório do Github e em seu próprio diretório, localizado em .github/workflows/.

Quando ocorre um push no repositório, o Github verifica se existe a pasta de workflows e, caso exista algum arquivo YAML, é criado os workflows no repositório.

Componentes do Workflow

Abaixo seguem alguns campos que podem ser utilizados no arquivo de workflow.

name: campo opcional que define o nome do workflow que será exibido no repositório.
on: campo que define os eventos que irão disparar o seu workflow.
jobs: campo que define os jobs deste workflow. O job tem os seguintes campos:
- runs-on: define o runner do job.
- steps: declara os steps do job. O step tem os seguintes campos:
- uses: define qual action será utilizada neste step do job.
- with: podemos configurar alguns atributos que são utilizadas pela action definida.
- run: define o commando que será executado no runner.

Na documentação do Github podemos ver toda sintaxe disponível para construir um workflow.

Primeiro Exemplo

Abaixo segue um exemplo de workflow (arquivo .github/workflows/sample.yml):

name: Github Exemplo

on: [push]

jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

No workflow declaramos, em on: [push], que deverá rodar sempre que ocorrer um push em qualquer branch do repositório.
Também é possível limitar as branches que queremos utilizar no disparo do workflow, exemplo:

on:
  push:
    branches:
      - main # executa nos pushes na main
      - 'releases/**' # executa nas branches com prefixo `releases/`

Na documentação do Github podemos ver a variedade de opções de ações que podemos utilizar para disparar um workflow.

No workflow também definimos o nosso workflow a executar os seguintes passos:

uses: actions/checkout@v2: efetua o git clone do nosso repositório;
uses: actions/setup-node@v2: utiliza um action para configurar o Nodejs v14;
run: npm install -g bats: executa o Npm install para instalar o bats globalmente;
run: bats -v: executa o bats instalado anteriomente.

Perceba que os steps do job são executados sequencialmente e os steps seguintes dependem do step anterior.
Isso mostra que o estado do nosso runner é compartilhado dentro do job, logo, podemos instalar e configurar o runner para utilizar tudo que o nosso projeto dependa para fazer build e publicação.

Alguns exemplos:

configurar o Docker
configurar credenciais da nossa cloud
configurar versões das linguagens e ferramentas

Na aba Actions do repositório no Github é possível visualizar a execução desse workflow.

Exemplo de Workflow Completo

Para concretizar melhor o poder de introduzir o Github Actions no seu ciclo de vida de desenvolvimento de software.
Vamos visualizar um exemplo de uma aplicação Java onde queremos definir um CI que faça o build, teste e publicação do nosso artefato gerado.

O nosso projeto está utilizando o Maven como gerenciado de dependências e de build. Nele temos configurado os plugins necessários para executar os testes e gerar um relatório do resultado da execução e da cobertura em HTML. Também temos configurado o nosso repositório de artefatos para utilizar o Github Artifacts.

Passos executados pelo workflow:

faça o build da aplicação
rode os testes da aplicação
armazene o resultado dos testes para podemos consultar posteriomente
efetuar publicação do nosso artefado construído para o repositório

Workflow

Abaixo segue o arquivo que define nosso workflow com os comentários demonstrados suas capactidades:

name: Java Workflow Example - Build, Test and Deploy

# configuramos para rodar apenas quando houver um push na master
on:
  push:
    branches:
      - master

jobs:
  # `build` é o nome do job
  build:
    # nome para exibir no repositório
    name: Build, Test and Deploy

    # utilizamos uma instância do ubuntu como runner
    runs-on: ubuntu-latest

    steps:
      # utilizamos a action checkout para fazer o git clone no runner
      - uses: actions/checkout@v2

      # utilizamos a action setup-java para configurar a versão necessária do JDK
      - name: Set up JDK 11
        uses: actions/setup-java@v2
        with:
          distribution: 'adopt'
          java-version: 11
          architecture: x64

      # aqui podemos configurar um cache para cachear as dependências do projeto,
      # isso vai permitir que as próximas execuções do workflow sejam mais rápidas
      # visto que as dependências já estarão disponibilizadas para o runner
      # nota: utilizamos um hash do arquivo POM.xml, então quando o alterarmos,
      # as dependências são baixadas novamente
      - name: Cache Maven packages
        uses: actions/cache@v2
        with:
          path: ~/.m2
          key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
          restore-keys: ${{ runner.os }}-m2

      # aqui apenas definimos o commando para executar no runner
      - name: Maven Test
        run: mvn test

      # aqui criamos a pasta para armazenar o relatório dos testes
      - run: mkdir coverage-report && cp -r target/site/jacoco/* coverage-report

      # aqui utilizamos um action para registrar o resultado do teste no nosso workflow,
      # caso ocorra alguma falha em algum teste, ficará explicito nos logs de execução aba Actions
      - name: Publish Test Report
        if: ${{ always() }}
        uses: scacap/action-surefire-report@v1

      # aqui utilizamos um action para fazer a publicação do relatório de testes,
      # esse relatório pode ser baixado nos detalhes de execução do workflow
      - uses: actions/upload-artifact@v2
        with:
          name: Test Coverage Report
          path: coverage-report

      # fazemos construção e publicação do artefato construído
      - name: Maven Build and Publish
        run: mvn -B deploy
        env:
          # com estamos utilizado o Github Artifact, passamos o token do repositório para fazer upload
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      # copiamos o artefato construído para uma pasta específica
      - run: mkdir dist && cp target/*.jar dist

      # aqui fazemos o publicação do artefato para que possa ser baixado nos detalhes de execução do workflow
      - uses: actions/upload-artifact@v2
        with:
          name: Package
          path: dist

O workflow acima é bem útil visto que tem todo nosso ciclo de desenvolvimento junto ao repositório, facilitando a visualização e entendimento de todos.

Após executar o workflow podemos ver o seu resultado, como no exemplo abaixo:

E o Github também nos disponibiliza algumas páginas que nos permite construir alguns dashboards para incluir no README do nosso repositório, facilitando a visualização do histórico e estado atual do projeto.

O projeto de exemplo utilizado aqui pode ser acessado no seus repositório no Github, nele está o projeto Java e outros workflows que utilizei em diferentes testes.

Conclusão

O Github Actions é uma ferramenta bem interessante, muito versátil e de fácil customização e utilização.
A grande vantagem que vejo é a enorme biblioteca de Actions disponbilizada pela comunidade e por fornecedores (Oracle, Microsoft, Google, Github, etc) que nos permitem fazer qualquer passo necessário.

E por estar toda definida com uma sintaxe de fácil leitura e junto ao projeto, o ciclo de desenvolvimento fica claro para todos que estão na equipe, desde o estagiário até o sênior, o que facilita o onboarding e o compartilhamento de informações no time.

Referências

Spring Boot - Estratégias para testar Rest API

Wesley Egberto — Thu, 03 Jun 2021 20:28:57 +0000

Spring Boot - Estratégias para testar Rest API

Para efetuar o teste de uma aplicação Spring Boot com REST API temos dois métodos:

Inside-server test:
- Standalone-mode: usar MockMVC sem contexto
- Spring context: usar MockMVC gerenciado pelo Spring
Outside-server test
- SpringBootTest com mock: usar MockMVC
- Integration test: usar RestTemplate ou TestRestTemplate

Independente da forma de configuração do testes, a escrita será similar, variando apenas na forma de mandar o body da requisição onde podemos escrever o JSON puro ou serializar um objeto.

Inside-Server Test

MockMVC com Standalone-mode

Podemos executar o teste em standalone-mode onde o contxto do Spring não é carregado.
Nele mockamos as dependências da controller e instânciamos outros beans necessários manualmente.

JUnit 4: utiliza o runner MockitoJUnitRunner
JUnit 5: utiliza a extensão MockitoExtension

Usamos a classe MockMvcBuilders para criar o contexto para teste fornecendo todas as peças necessárias:

@ExtendWith(MockitoExtension.class)
public class PetsControllerMockMvcStandaloneTest {
    private MockMvc mvc;

    @Mock
    private PetsRepository petsRepository;

    @InjectMocks
    private PetsController petsController;

    private JacksonTester<Pet> json;

    @BeforeEach
    public void setup() {
        // se estiver usando JUnit 4
        // MockitoAnnotations.initMocks(this);

        // não podemos usar @AutoConfigureJsonTesters (já que não existe o contexto do Spring - então inicializamos na mão)
        JacksonTester.initFields(this, new ObjectMapper());

        MockMvcBuilders.standaloneSetup(petsController)
                .setControllerAdvice(new PetExceptionHandler())
                .addFilters(new ApiVersionFilter())
                .build();
    }

    @Test
    public void should_return_existing_pet() throws Exception {
        given(petsRepository.findById(42))
                .willReturn(Optional.of(new Pet(42, "Marley", "Wesley")));

        MockHttpServletResponse response = mvc.perform(
                    get("/pets/42").accept(MediaType.APPLICATION_JSON)
                )
                .andReturn()
                .getResponse();

        assertThat(response.getStatus()).isEqualTo(HttpStatus.OK.value());
        assertThat(response.getContentAsString())
            .isEqualTo(
                json.write(new Pet(42, "Marley", "Wesley")).getJson()
            );
    }

    @Test
    public void should_return_not_found_for_non_existing_pet() throws Exception {
        given(petsRepository.findById(42))
                .willThrow(new PetNotFoundException());

        MockHttpServletResponse response = mvc.perform(
                    get("/pets/42").accept(MediaType.APPLICATION_JSON)
                )
                .andReturn()
                .getResponse();

        assertThat(response.getStatus()).isEqualTo(HttpStatus.NOT_FOUND.value());
        assertThat(response.getContentAsString()).isEmpty();
    }

    @Test
    public void should_create_new_pet() throws Exception {
        MockHttpServletResponse response = mvc.perform(
                    post("/pets")
                        .accept(MediaType.APPLICATION_JSON)
                        .contentType(MediaType.APPLICATION_JSON)
                        .content(
                            json.write(new Pet("Marley", "Wesley")).getJson()
                        )
                )
                .andReturn()
                .getResponse();

        assertThat(response.getStatus()).isEqualTo(HttpStatus.CREATED.value());

        ArgumentCaptor<Pet> argCaptor = ArgumentCaptor.forClass(Pet.class);
        verify(petsRepository).save(argCaptor.capture());
        Pet pet = argCaptor.getValue();

        assertThat(pet.getId()).isEqualTo(0);
        assertThat(pet.getName()).isEqualTo("Marley");
        assertThat(pet.getOwner()).isEqualTo("Wesley");
    }

    @Test
    public void should_add_api_version_header() throws Exception {
        MockHttpServletResponse response = mvc.perform(
                    get("/pets/42").accept(MediaType.APPLICATION_JSON)
                )
                .andReturn()
                .getResponse();

        assertThat(response.getStatus()).isEqualTo(HttpStatus.OK.value());
        assertThat(response.getHeaders("X-PETS-VERSION")).containsOnly("v1");
    }
}

MockMVC com Spring Context

Podemos executar o teste inicializando o contexto do Spring.
O runner provido pelo Spring irá carregar todo contexto necessário para o controle (mocks, filters, advices, etc).
Esse formato é mais considerado Integration Test porque outros elementos do Spring e da aplicação (filters, advices) são adicionados automaticamente.

Nota: no Spring Boot 2.1+, as anotações @...Tests do Spring já são decorados com @ExtendWith(SpringExtension.class)

@AutoConfigureJsonTesters
@WebMvcTest(PetsController.class)
public class PetsControllerMockMvcWithContextTest {
    @Autowired
    private MockMvc mvc;

    @MockBean
    private PetsRepository petsRepository;

    // inicializado automaticamente pelo @AutoConfigureJsonTesters
    @Autowired
    private JacksonTester<Pet> json;

    @Test
    public void should_return_existing_pet() throws Exception {
        given(petsRepository.findById(42))
                .willReturn(Optional.of(new Pet(42, "Marley", "Wesley")));

        MockHttpServletResponse response = mvc.perform(
                    get("/pets/42").accept(MediaType.APPLICATION_JSON)
                )
                .andReturn()
                .getResponse();

        assertThat(response.getStatus()).isEqualTo(HttpStatus.OK.value());
        assertThat(response.getContentAsString())
            .isEqualTo(
                json.write(new Pet(42, "Marley", "Wesley")).getJson()
            );
    }

    @Test
    public void should_return_not_found_for_non_existing_pet() throws Exception {
        given(petsRepository.findById(42))
                .willThrow(new PetNotFoundException());

        MockHttpServletResponse response = mvc.perform(
                    get("/pets/42").accept(MediaType.APPLICATION_JSON)
                )
                .andReturn()
                .getResponse();

        assertThat(response.getStatus()).isEqualTo(HttpStatus.NOT_FOUND.value());
        assertThat(response.getContentAsString()).isEmpty();
    }

    @Test
    public void should_create_new_pet() throws Exception {
        MockHttpServletResponse response = mvc.perform(
                    post("/pets")
                        .accept(MediaType.APPLICATION_JSON)
                        .contentType(MediaType.APPLICATION_JSON)
                        .content(
                            json.write(new Pet("Marley", "Wesley")).getJson()
                        )
                )
                .andReturn()
                .getResponse();

        assertThat(response.getStatus()).isEqualTo(HttpStatus.CREATED.value());

        ArgumentCaptor<Pet> argCaptor = ArgumentCaptor.forClass(Pet.class);
        verify(petsRepository).save(argCaptor.capture());
        Pet pet = argCaptor.getValue();

        assertThat(pet.getId()).isEqualTo(0);
        assertThat(pet.getName()).isEqualTo("Marley");
        assertThat(pet.getOwner()).isEqualTo("Wesley");
    }

    @Test
    public void should_add_api_version_header() throws Exception {
        MockHttpServletResponse response = mvc.perform(
                    get("/pets/42").accept(MediaType.APPLICATION_JSON)
                )
                .andReturn()
                .getResponse();

        assertThat(response.getStatus()).isEqualTo(HttpStatus.OK.value());
        assertThat(response.getHeaders("X-PETS-VERSION")).containsOnly("v1");
    }
}

Outside-Server Test

É utilizado a anotação @SprintBootTest.
Spring inicializa toda a aplicação com todas suas dependências, o que torna o teste mais lento.
Um webserver real pode ou não ser inicializado (dependendo do valor da propriedade webEnvironment da anotação).
É possível ainda utilizar mocks ou desativar alguns componentes.

`@SpringBootTest` com MockMvc (sem webserver real)

O Spring inicializa toda a aplicação sem um webserver real.

Quando usamos a anotação sem parâmetros ou com webEnvironment = WebEnvironment.MOCK estamos criando um contexto igual ao MockMVC com contexto do Spring (usando extensão @SpringExtension).

@SpringBootTest
@AutoConfigureJsonTesters
@AutoConfigureMockMvc
public class PetsControllerSpringBootMockTest {
    @Autowired
    private MockMvc mvc;

    @MockBean
    private PetsRepository petsRepository;

    // inicializado automaticamente pelo @AutoConfigureJsonTesters
    @Autowired
    private JacksonTester<Pet> json;

    @Test
    public void should_return_existing_pet() throws Exception {
        given(petsRepository.findById(42))
                .willReturn(Optional.of(new Pet(42, "Marley", "Wesley")));

        MockHttpServletResponse response = mvc.perform(
                    get("/pets/42").accept(MediaType.APPLICATION_JSON)
                )
                .andReturn()
                .getResponse();

        assertThat(response.getStatus()).isEqualTo(HttpStatus.OK.value());
        assertThat(response.getContentAsString())
            .isEqualTo(
                json.write(new Pet(42, "Marley", "Wesley")).getJson()
            );
    }

    @Test
    public void should_return_not_found_for_non_existing_pet() throws Exception {
        given(petsRepository.findById(42))
                .willThrow(new PetNotFoundException());

        MockHttpServletResponse response = mvc.perform(
                    get("/pets/42").accept(MediaType.APPLICATION_JSON)
                )
                .andReturn()
                .getResponse();

        assertThat(response.getStatus()).isEqualTo(HttpStatus.NOT_FOUND.value());
        assertThat(response.getContentAsString()).isEmpty();
    }

    @Test
    public void should_create_new_pet() throws Exception {
        MockHttpServletResponse response = mvc.perform(
                    post("/pets")
                        .accept(MediaType.APPLICATION_JSON)
                        .contentType(MediaType.APPLICATION_JSON)
                        .content(
                            json.write(new Pet("Marley", "Wesley")).getJson()
                        )
                )
                .andReturn()
                .getResponse();

        assertThat(response.getStatus()).isEqualTo(HttpStatus.CREATED.value());

        ArgumentCaptor<Pet> argCaptor = ArgumentCaptor.forClass(Pet.class);
        verify(petsRepository).save(argCaptor.capture());
        Pet pet = argCaptor.getValue();

        assertThat(pet.getId()).isEqualTo(0);
        assertThat(pet.getName()).isEqualTo("Marley");
        assertThat(pet.getOwner()).isEqualTo("Wesley");
    }

    @Test
    public void should_add_api_version_header() throws Exception {
        MockHttpServletResponse response = mvc.perform(
                    get("/pets/42").accept(MediaType.APPLICATION_JSON)
                )
                .andReturn()
                .getResponse();

        assertThat(response.getStatus()).isEqualTo(HttpStatus.OK.value());
        assertThat(response.getHeaders("X-PETS-VERSION")).containsOnly("v1");
    }
}

É mais recomendado utilizar MockMVC com extensão @SpringExtension porque é mais controlável para testes de um controller específico.

`@SpringBootTest` com RestTemplate ou TestRestTemplate (com webserver real)

O Spring inicializa toda a aplicação com um webserver real (tomcat, jetty).
Para os testes utilizamos o RestTemplate ou TestRestTemplate, que nos fornece algumas features a mais para facilitar os testes de integração.

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
public class PetsControllerSpringBootTest {
    @MockBean
    private PetsRepository petsRepository;

    @Autowired
    private TestRestTemplate restTemplate;

    @Test
    public void should_return_existing_pet() throws Exception {
        given(petsRepository.findById(42))
                .willReturn(Optional.of(new Pet(42, "Marley", "Wesley")));

        ResponseEntity<Pet> response = restTemplate.getForEntity("/pets/42", Pet.class);

        assertThat(response.getStatusCode()).isEqualTo(HttpStatus.OK);
        assertThat(response.getBody().equals(new Pet(42, "Marley", "Wesley")));
    }

    @Test
    public void should_return_not_found_for_non_existing_pet() throws Exception {
        given(petsRepository.findById(42))
                .willThrow(new PetNotFoundException());

        ResponseEntity<Pet> response = restTemplate.getForEntity("/pets/42", Pet.class);

        assertThat(response.getStatusCode()).isEqualTo(HttpStatus.NOT_FOUND);
        assertThat(response.getBody()).isNull();
    }

    @Test
    public void should_create_new_pet() throws Exception {
        ResponseEntity<Pet> response = restTemplate.postForEntity("/pets",
                new Pet("Marley", "Wesley"), Pet.class);

        assertThat(response.getStatusCode()).isEqualTo(HttpStatus.CREATED);

        ArgumentCaptor<Pet> argCaptor = ArgumentCaptor.forClass(Pet.class);
        verify(petsRepository).save(argCaptor.capture());
        Pet pet = argCaptor.getValue();

        assertThat(pet.getId()).isEqualTo(0);
        assertThat(pet.getName()).isEqualTo("Marley");
        assertThat(pet.getOwner()).isEqualTo("Wesley");
    }

    @Test
    public void should_add_api_version_header() throws Exception {
        ResponseEntity<Pet> response = restTemplate.getForEntity("/pets/42", Pet.class);

        assertThat(response.getStatusCode()).isEqualTo(HttpStatus.OK);
        assertThat(response.getHeaders().get("X-PETS-VERSION")).containsOnly("v1");
    }
}

Nota

Vale notar que nos testes estamos mockando a classe PetsRepository porque queremos testar isoladamente nossa API, aqui queremos testar:

serialização das models
filters
validações na controller
response com headers

O projeto de exemplo está no github.

Angular - Testes de Pipes e Services

Wesley Egberto — Sat, 15 May 2021 04:06:58 +0000

No post anterior falamos sobre o básico de testes, neste iremos iniciar os testes unitários das estruturas do Angular.

Outros posts da série:

Estruturas que iremos testar:

Pipes
Services

Pipes

Como mostrado no post anterior os testes de Pipes não tem segredo.
Podemos suprir as dependências da classe utilizando mocks ou instâncias manuais - recomendo usar mock de modo que possa a testar de fato apenas as regras da pipe.

Sempre que possível, é interessante testar todas as possíveis variações dos valores de entrada (limites do domínio de entrada) para que não tenhamos nenhum caso não tratato, pois não saberemos quem poderá utilizar nossa Pipe.

Dado a pipe abaixo no arquivo strength.pipe.ts:

import { Pipe, PipeTransform } from '@angular/core';

@Pipe({ name: 'strength' })
export class StrengthPipe implements PipeTransform {
  transform(value: number): string {
    if (value < 0) {
      return '(invalid)';
    } else if (value < 10) {
      return `${value} (weak)`;
    } else if (value >= 10 && value < 20) {
      return `${value} (strong)`;
    } else {
      return `${value} (unbelievable)`;
    }
  }
}

Seguindo o padrão do Angular, criaremos o arquivo de teste strength.pipe.spec.ts:

import { StrengthPipe } from './strength.pipe';

describe('Pipe: Strength', () => {
  let pipe: StrengthPipe;

  beforeEach(() => {
    pipe = new StrengthPipe();
  });

  it('should display the strengh with sufix `weak` when between 0 and 10', () => {
    expect(pipe.transform(0)).toBe('0 (weak)');
    expect(pipe.transform(5)).toBe('5 (weak)');
    expect(pipe.transform(9)).toBe('9 (weak)');
  });

  it('should display the strengh with sufix `strong` when between 10 and 20', () => {
    expect(pipe.transform(10)).toBe('10 (strong)');
    expect(pipe.transform(15)).toBe('15 (strong)');
    expect(pipe.transform(19)).toBe('19 (strong)');
  });

  it('should display the strengh with sufix `unbelievable` when >= 20', () => {
    expect(pipe.transform(20)).toBe('20 (unbelievable)');
    expect(pipe.transform(57)).toBe('57 (unbelievable)');
    expect(pipe.transform(100)).toBe('100 (unbelievable)');
  });

  it('should display the invalid when < 0', () => {
    expect(pipe.transform(-1)).toBe('(invalid)');
  });
});

Services

Os testes de services tem uma estrutura similar aos testes de pipes, o que pode complicar os casos de testes são as dependências do service.
Podemos ter uma service que apenas gerencia estado, executa alguma lógica de negócio ou que realiza uma requisição HTTP para uma API.

Caso nossa service utilize alguma lib é recomendado verificar se tal lib tem uma versão de testes que nos ajude a mockar ou simular seu comportamento, permitindo assim uma melhor qualidade no teste.

Para as services normalmente podemos ter:

testes isolados: casos onde não existe dependência ou casos em que criamos mock de todas elas;
testes integrados: casos onde testamos o comportamento da nossa service junto com as suas dependências.

Service Sem Dependências

Abaixo segue um exemplo de uma service que gerencia o estado em um array.

Arquivo message.service.ts:

import { Injectable } from '@angular/core';

@Injectable()
export class MessageService {
  messages: string[] = [];

  add(message: string) {
    this.messages.push(message);
  }

  clear() {
    this.messages = [];
  }
}

Arquivo de teste message.service.spec.ts:

import { MessageService } from './message.service';

describe('MessageService', () => {
  // cut (class under testing) - cute para não pegarmos aversão aos testes =)
  let cut: MessageService = null;

  beforeEach(() => {
    cut = new MessageService();
  });

  it('should have no message when starting', () => {
    expect(cut.messages.length).toBe(0);
  });

  it('should add a message and keep it', () => {
    cut.add('message1');

    expect(cut.messages.length).toBe(1);
    const storedMessage = cut.messages[0];
    expect(storedMessage).toBe('message1');
  });

  it('should remove all messages when clear is called', () => {
    cut.add('message to remove');

    cut.clear();

    expect(cut.messages.length).toBe(0);
  });
});

Service com Dependência

Para criar um teste unitário de uma service que tem uma dependência qualquer podemos utilizar o Jasmine para nos ajudar a criar o mock dessa dependência de forma que nos permita mockar seu retorno ou verificar se um método foi chamado.

Como exemplo, tomemos o service abaixo que depende de uma classe LogService que tenha um método log(string): boolean e que sempre precisa logar o resultado do cálculo:

@Injectable()
export class CalculationService {
  constructor(private readonly logger: LogService) {}

  calculate(): number {
    const answer = 42; // magic
    const logged = this.logger.log(`Calculation result: ${answer}`);
    // alguma regra que obrigue sempre a logar o resultado
    if (!logged)
      throw new Error("Result was not logged");
    return answer;
  }
}

Podemos criar o teste calculation.service.spec.ts abaixo:

describe('CalculationService', () => {
  let mockedLogger: LogService;

  let service: CalculationService;

  beforeEach(() => {
    // criamos o mock da nossa dependência passando os métodos logados
    mockedLogger = jasmine.createSpyObj(['log']);

    // instanciamos nossa service passando a sua dependência
    service = new CalculationService(mockMessageService);
  });

  describe('calculate', () => {
    it('should return 42 and log it', () => {
      // mockamos o retorno do método que dependemos (informa que logou)
      mockMessageService.log.and.returnValue(true);

      const result = service.calculate();

      // validamos o retorno da service
      expect(result).toBe(42);
      // verificamos se o método foi chamado
      expect(mockedLogger.log).toHaveBeenCalledTimes(1);
      // também podemos verificar se foi passado o argumento esperado
      expect(mockMessageService.add).toHaveBeenCalledWith('Calculation result: 42');
    });

    // caso onde testamos o comportamento caso não seja logado
    it('should throw error if result was not logged', () => {
      // mockamos o retorno informando que não logou
      mockMessageService.log.and.returnValue(false);

      // podemos também testar o lançamento de erros
      expect(() => service.calculate()).toThrow(new Error("Result was not logged"));
    });
  });
});

Service com HTTP Client

Para testar uma service que faz uma requisição HTTP podemos utilizar um módulo de teste HttpClientTestingModule que o Angular disponibiliza.

Para os testes com requisição HTTP precisamos configurar e inicializar o módulo de teste do Angular de modo que ele configure um mock do HttpClient que faça uma requisição falsa ao capturar a URL que foi chamada e retorne um response que precisamos para testar o comportamento da service.

Para configurar o módulo de testes utilizaremos a classe TestBed que o Angular fornece para facilitar a configuração do teste.
Essa configuração precisa ser feita antes dos nossos casos de testes, para isso utilizaremos o método beforeEach que é invocado antes de cada teste.

Ainda no método beforeEach, precisamos recuperar uma instância da classe HttpTestingController que o Angular configura para nós, com ela iremos poder validar quais URLs foram chamadas, quantoas vezes e forçar um retorno simulado.

Com a service hero.service.ts:

import { Injectable } from '@angular/core';
import { HttpClient, HttpHeaders } from '@angular/common/http';

import { Observable, of } from 'rxjs';
import { tap } from 'rxjs/operators';

import { Hero } from './hero';

const httpOptions = {
  headers: new HttpHeaders({ 'Content-Type': 'application/json' })
};

@Injectable()
export class HeroService {
  constructor(private http: HttpClient) { }

  // a regra da nossa service é adicionar um simples prefixo no nome
  getHeroes(): Observable<any> {
    return this.http.get('/api/heroes')
      .pipe(tap(heroes => {
        if (heroes && heroes.length) {
          heroes.forEach(hero => {
            hero.name = `Super ${hero.name}`;
          });
        }
      }));
  }

  saveHero(hero: any): Observable<Hero> {
    return this.http.post('/api/heroes', hero, httpOptions);
  }

Podemos criar um caso de teste hero.service.spec.ts:

import { TestBed, inject } from '@angular/core/testing';
import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';

import { HeroService } from './hero.service';
import { MessageService } from './message.service';

describe('HeroService', () => {
  let httpTestingController: HttpTestingController;

  let heroSvc: HeroService;

  beforeEach(() => {
    // no `providers` precisamos adicionar todas as dependências da nossa service
    TestBed.configureTestingModule({
      imports: [ HttpClientTestingModule ],
      providers: [ HeroService ]
    });

    // recuperamos a instância do controle de teste
    httpTestingController = TestBed.get(HttpTestingController);
    // recuperamos nossa service já configurada com sua dependência (HttpClient)
    heroSvc = TestBed.get(HeroService);
  });

  // aqui garantimos que nossa service e suas dependências conseguem ser criadas
  it('should be able to create a service', inject([HeroService], (heroService: HeroService) => {
    expect(heroService).toBeDefined();
  }));

  // caso nosso método tenha vários testes é interessante agrupar em um `describe` para facilitar a visualização no relatório
  describe('getHeroes', () => {
    // caso onde verificamos se a URL correta foi chamada
    it('should call get with the correct URL', () => {
      // aqui nosso subscriber não fará nada visto que estamos interessando em testar a requisição
      heroSvc.getHeroes().subscribe();

      // podemos verificar a requisição já validando se foi feita para determinada URL
      httpTestingController.expectOne('/api/heroes');

      // verifica as expectativas configuradas no controle de teste
      httpTestingController.verify();
    });

    // case onde verificamos o retorno da service
    it('should update the name with Super prefix', () => {
      heroSvc.getHeroes()
        // aqui podemos utilizar o subscriber para verificar o resultado
        .subscribe(heroes => {
          expect(heroes).toBeTruthy();
          expect(heroes.length).toBe(1);

          const hero = heroes[0];
          expect(hero.name).toBe('Super Odair');
          expect(hero.strength).toBe(42);
        });

      // `expectOne` captura a requisição e retorna um `TestRequest` onde podemos configurar a resposta da requisição
      const req = httpTestingController.expectOne('/api/heroes');
      // aqui setamos o JSON de retorno da URL
      req.flush([ { id: 42, name: 'Odair', strength: 42 } ]);

      // rodamos nossa verificação
      httpTestingController.verify();
    });
  });

  // caso de teste para salvar
  describe('saveHero', () => {
    it('should save a hero', () => {
      heroSvc.saveHero({ name: 'Mr. Anderson', strength: 42 })
        .subscribe(hero => {
          expect(hero).toBeTruthy();
          // verificamos se a service não alterou o resultado da API
          expect(hero.name).toBe('Neo');
          expect(hero.strength).toBe(42);
          // validamos o ID gerado
          expect(hero.id).toBe(1)
        });

      const req = httpTestingController.expectOne('/api/heroes');

      // validamos o JSON da requisição para verificar se service não alterou o que a tela passou
      expect(req.request.body.name).toBe('Mr. Anderson');
      expect(req.request.body.strength).toBe(42);

      // mockamos o retorno criado pela API para rodar o subscriber
      // retornamos outro nome para verificar se a service retornou o response da API =)
      req.flush({ id: 1, name: 'Neo', strength: 42 });
      httpTestingController.verify();
    });
  });
});

A classe de teste estruturada acima irá gerar uma seção no relatório do Karma abaixo:

No próximo post criaremos alguns testes de componentes de tela.

Maven - Resources Dinâmicos

Wesley Egberto — Mon, 26 Apr 2021 16:59:06 +0000

Nossos projetos em Java geralmente possuem vários arquivos de configuração do projeto e do ambiente de execução, como por exemplo a configuração do JPA (persistence.xml), customização de mensagens do JSF ou configuração do JSF (faces-config.xml).

Esses arquivos são os recursos do nosso projeto e geralmente ficam na pasta main/resources ou test/resources. Normalmente temos uma variação do arquivo para cada ambiente que são, ou não, mantidos juntos ao nosso código fonte no repositório (grande falha de segurança pois estamos deixando dados de acesso ao ambiente de produção à vista) ou mesmo são copiados ou alterados manualmente após o build :s.

O Maven possui um plugin chamado Resources que é responsável pela cópia dos resources do nosso projeto. Por padrão, o plugin apenas copia os arquivos da nossa pasta src (main ou de test) para a pasta de build do projeto (target). No entanto, o plugin Resources consegue fazer uso de outro plugin do Maven para efetuar um processamento do arquivo, permitindo assim deixarmos algumas partes dele dinâmicas.

Esse plugin é o Maven Filtering, ele nos permite definir nos arquivos de recursos varáveis que possam ser substituídas no momento do build do nosso projeto. Por exemplo, no nosso arquivo de configuração do JPA poderíamos utilizar uma variável que contém o nome do Data Source que iremos utilizar, e para cada ambiente podemos subsituir essa variável com o valor adequado. Isso é interessante caso você tenha um pipeline em um CI (Continuous Integration), pois nele você pode definir o nome do Data Source de Teste através do script de build de teste.

Abaixo segue um exemplo do persistence.xml que contém uma variável datasource.name que será utilizada dinamicamente de acordo com o script de build.

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
  <persistence-unit name="EffectiveJavaEE" transaction-type="JTA">
    <jta-data-source>${datasource.name}</jta-data-source>
    <properties>
      <property name="javax.persistence.schema-generation.database.action" value="drop-and-create" />
    </properties>
  </persistence-unit>
</persistence>

Como pode ver, uma variável é definida entre ${}, assim como as Expression Language do JSP.

Para ativar o Filtering durante o build, precisamos adicionar no nosso POM.xml a seção build abaixo.

<build>
  <resources>
    <resource>
      <directory>src/main/resources/META-INF</directory>
      <filtering>true</filtering>
    </resource>
  </resources>
</build>

Dentro de resources, podemos definir um arquivo ou uma pasta com arquivos que serão processadas e também ativamos o Filtering através da tag filtering.

Os valores dessas variáveis podem ser definida de várias formas:

Arquivos properties no formato: <variável>=<valor>
Valores definidos na seção <build>/<filters> do nosso POM.xml
Propriedades definidas nas seções <properties> do nosso POM.xml
Propriedades passadas na execução do Maven (flag -D) no formato <variável>=<valor>
Abaixo segue um exemplo de um script que faz o build do nosso projeto passando um Data Source (poderia ser colocado no pipeline do nosso Jenkins).

mvn clean install -Ddatasource.name=java:/ds/BancoDeTestes
Em negrito, segue a nossa variável definida no nosso persistence.xml que após o build terá o seguinte resultado:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
 <persistence-unit name="EffectiveJavaEE" transaction-type="JTA">
   <jta-data-source>java:/ds/BancoDeTestes</jta-data-source>
   <properties>
     <property name="javax.persistence.schema-generation.database.action" value="drop-and-create" />
   </properties>
 </persistence-unit>
</persistence>

Com isso, podemos ver o quão poderoso o Maven pode ser e o quanto ele pode facilitar nossa vida. Ao invés de precisarmos sempre ter que editar o build gerado ou ter vários arquivos, um para cada ambiente, podemos simplesmente passar como argumento no build ou um arquivo com nossos valores.

Alguns exemplos plausíveis de uso seria no buid do projeto onde poderíamos setar dinâmicamente o IP ou nome do nosso container Docker que contém nosso banco de dados para testes, poderíamos setar o IP no arquivo standalone.xml do nosso Wildfly ou mesmo no script que adiciona nosso datasource nele.

Spring - Exception Handler

Wesley Egberto — Mon, 26 Apr 2021 16:52:44 +0000

Para começar, certifique que tem a dependência no seu POM ou Gradle.

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Tratamento Padrão

O tratamento de erro padrão do Spring oferece uma forma out-of-the-box que responde dependendo do Content-type.

Caso o Content-Type seja text/html o tratamento de erro irá encaminhar o request para uma página de erro White label error page. Caso você adicione um mapping específico para "/error" então o Spring utilizará esse cara ao invés do White label error page.
Caso o Cotent-type seja JSON o tratamento de erro retornará um objeto com as seguintes propriedades: error, message, path, status e timestamp.

A página de erro pode ser desabilitada ao adicionar a linha abaixo no seu .properties.

server.error.whitelabel.enabled=false

Tratamento Customizado

Spring fornece uma maneira bem simples e limpa que nos permite tratar exceptions que ocorrem durante a execução de um método do nosso controller MVC/REST. Podemos tratar e retornar um JSON ou encaminhar para uma página especifica de erro.

Usando @ResponseStatus

A primeira forma nos permite tratar apenas o retorno do nosso controller. Na nossa exception adicionamos a anotação @ResponseStatus que permite customizar o HTTP status e o header reason do nosso response. O response ainda será retornado utilizando o tratamento padrão (error page ou JSON padrão) caso não tenha sido definido uma págian ou um handler.

@ResponseStatus(code = HttpStatus.BAD_REQUEST, reason = "We can't handle your request =(")
public class CustomException extends RuntimeException {
}

@RestController
@RequestMapping("/api")
class HelloController {
   @GetMapping("custom")
   public String customResponseFailure() {
      throw new CustomException();
   }
}

Quando uma exception do tipo CustomException for lançada o tratamento padrão de erro do Spring entrará em ação mas utilizará o nosso HTTP status e adicionará o header reason no response.

Usando @ExceptionHandler

A segunda forma mais interessante é criar um método para tratar exceptions específicas. Esta forma nos permite cria um método para tratar a exception adequadamente e então encaminhar para uma página específica ou retornar uma entidade customizada.

Se anotarmos um método de uma controller então todos as exceptions daquela controller que não tenham sejam anotadas com @ResponseStatus serão tratadas por ela mas caso queiramos criar um handler para todas as controllers precisamos criar um Advice.

Temos dois tipos de Advice: ControllerAdvice e RestControllerAdvice. O ControllerAdvice segue a semântica do @Controller, então no fim do tratamento ele redireciona para a view definida. O RestControllerAdvice segue o @RestController, então retorna seu objeto serializado direto no response.

Controller com @ExceptionHandler

@Controller
@RequestMapping("/web")
public class PageController {
   @GetMapping("customerrorpage")
   public String customErrorPage() {
      throw new NumberFormatException("We can't format your number");
   }

   @ExceptionHandler(NumberFormatException.class)
   public ModelAndView handleNumberFormatException(NumberFormatException nfex) {
      ModelAndView model = new ModelAndView("custom_error");
      model.addObject("errorMessage", nfex.getMessage());
      return model;
   }
}

Classe com ControllerAdvice e RestControllerAdvice

@ControllerAdvice
public class CustomPageExceptionHandler {
   @ExceptionHandler(NumberFormatException.class)
   public ModelAndView handleNumberFormatException(NumberFormatException nfex) {
      ModelAndView model = new ModelAndView("custom_error");
      model.addObject("errorMessage", nfex.getMessage());
      return model;
   }
}

@RestControllerAdvice
public class CustomJsonExceptionHandler {
   // podemos usar também @ResponseStatus
   @ResponseStatus(code =  HttpStatus.BAD_REQUEST)
   @ExceptionHandler(IllegalStateException.class)
   public String handleInvalidStateException(IllegalStateException rex, HttpServletResponse response) {
      System.err.println("Hey dev! We got an illegal state: " + rex.getMessage());
      response.addHeader("Reason", rex.getMessage());
      return "Sorry, we got some problem =(";
   }
}

Para maiores informações acessar links [2] e [3].

Exemplo

Projeto com exemplos: GitHub

Notas:

Ao usar Spring Bott com custom error page lembre-se de empacotar com WAR e adicionar deps do tomcat (veja [1])

Resumo do paper 'On The Criteria To Be Used In Decomposing Systems Into Modules' do Parnas

Wesley Egberto — Sun, 25 Apr 2021 07:21:15 +0000

Hoje resumirei um paper que foi citado no podcast sobre Academia e Universidade vs Mercado e Indústria do Hipster.Tech e que também foi resumido e comentado neste video do Alberto de Souza no seu canal Dev Eficiente.

Publicado em 1971, disponível em On The Criteria To Be Used In Decomposing Systems Into Modules (D.L. Parnas).

Disclaimer:
Não assuma nada aqui como verdade, foram notas que tomei direto do paper a partir do meu entendimento.
Recomendo que faça a leitura logo em seguida e valide o que você entendeu.

Problema

programas com uma grande quantidade de funcionalidades são grandes e complicados por natureza
é necessário um critério para decomposição do programa
a efetividade da modularização depende do critério utilizado para dividir os módulos

Módulos

Definição de modularização seguindo Gouthier e Pont:

uma segmentação bem definida do projeto garante modularidade do sistema
cada "tarefa" forma um módulo distinto e separado do programa
- ex.: módulo de pagamentos que envolve validação dados, cobrança do cartão, persistência da cobrança e tratamentos.
no momento da implementação, cada módulo com suas entradas e saídas são bem definidas, não há confusão sobre o conexão com outros módulos do sistema
a integridade do sistema pode ser testada de forma independente
erros de sistema e deficiências podem ser rastreados até o módulo específico ao limitar o escopo da busca de detalhes do erro

Pense em um módulo como uma unidade de trabalho.

Benefícios dos módulos:

gerencial:
- tempo de desenvolvimento pode ser encurtado
- grupos separados podem trabalhar em cada módulo com pouca comunicação (Nota pessoal: era o que se esperava mas hoje sabemos que precisamos de uma boa comunicação)
flexibilidade:
- mudanças podem ser feitas em um módulo sem afetar outro
compreensibilidade:
- é possível estudar o sistema um módulo de cada vez

Para maximizar tais benefícios é preciso dividir os módulos de forma apropriada.

Contribuição

Paper compara duas formas de dividir os módulos:

Decomposição 1: usa abordagem de fluxograma onde cada módulo é um grande passo de um processo.
Decomposição 2: usa ocultamento de informação como critério:
- cada módulo é caracterizado por ocultar as decisões tomadas na implementação;
- ao esconder as decisões, cada usuário do módulo não precisa saber o funcionamento interno associado com a decisão, e assim ao mudar essa decisão não deve haver impactos.

Exemplo analisado no paper:

Decomposição 1:

Módulo 1: Input
Módulo 2: Circular Shift
Módulo 3: Alphabetizing
Módulo 4: Output
Módulo 5: Master Control

Decomposição 2:

Módulo 1: Line Storage
Módulo 2: Input
Módulo 3: Circular Shifter
Módulo 4: Alphabetizer
Módulo 5: Output
Módulo 6: Master Control

Nota pessoal: as decomposições parecem iguais mas existe uma diferença sutil no seu uso em alguns módulos, onde um expõe detalhes da implementação (função que receber uma lista de palavras com uma divisão específica) enquanto a outra não expõe essa regra (apenas armazena a linha para que possam operar sobre ela). E ainda, a decomposição 1 tem um jeito bem estruturado em que passa a ideia de ser um fluxo direto, e a decomposição 2 não (normalmente é o que acontece, temos alguns módulos se comunicando através de todo o processo para resolver um problema).

Comparação

Apesar das decomposições serem parecidas, apenas são na representação executável. As representações para manutenção, documentação, entendimento e etc podem não ser parecidas.

Geral:
- ambos produziram programas que funcionam
- podem ser iguais após a compilação
Manutenção:
- se o formato da mensagem mudar, em ambas decomposições apenas um módulo será alterado
- se o formato do armazenamento ou caso não armazene mais, a decomposição 1 terá alteração em todos os módulos (vazou detalhes da implementação ao propagar a mensagem formatada) enquanto que a decomposição 2 apenas um módulo será alterado
Desenvolvimento independente:
- as interfaces entre os módulos da decomposição 1 são mais complexas que na decomposição 2 pois detalhes do formato da mensagem, armazenamento e etc vazou entre os módulos (pois são utilizados na entrada e saída)
Compreensibilidade:
- o autor acha o decomposição 2 mais fácil de entender:
- na decomposição 1 apenas é possível saber o que o sistema faz ao olhar todos os módulos e como eles funcionam em conjunto, algumas coisas em um módulo só farão sentido após entender o que o outro módulo faz
- Nota pessoal: nos cenários exemplificados, tenho tendência a concordar caso as funções expostas nos módulos tenham interface voltada ao problema (nome dos métodos, parâmetros de entrada e saída). Ex.: módulo de alphabetizer ordena uma lista de palavras, não me importa qual algoritmo usa ou porque, importa apenas que me retorna a lista ordenada. Aqui podemos ter uma assinatura sort(words: List<string>): SortedList<string>.

Hierarquia das Estruturas

Decomposição 1:

mapeia o programa em forma de árvore.
as funções só podem ser utilizadas por outras funções acima dela:
- Function 1 -> Function 2 -> Function 3

Decomposição 2:

o sistema tem uma hierarquia do programa com um todo.
- ex.: os módulos de output e alphabetizer precisam do shifter
alguns módulos mais baixo nível (sem dependências para iniciar) podem ser extraídos para utilizar em outro lugar
- ex.: line storage

Benefícios da hierarquia:

existe uma estrutura hierárquica se existe uma relação entre os módulos que pode ser parcialmente ordenada
- módulo A depende ou usa módulo B
- módulo A -> módulo B
partes do sistemas são simplificadas porque elas usam serviços de níveis inferiores
os níveis superiores podem ser retirados do programa e ainda podemos ter um programa utilizável (em outro problema talvez)

Independência:

estrutura hierárquica e decomposição limpa são propriedades independentes
embora decomposição 2 produza um programa hierárquico, é possível obter um resultado parecido através da abordagem da decomposição 1 - talvez com mais iterações

Método Proposto

começar pela lista de decisões de design que são prováveis de sofrerem mudanças e então construir os módulos de modo que essas decisões sejam ocultas
todo o conhecimento sobre o contexto do módulo precisa estar contido nele mesmo
- estrutura de dados, o procedimento de acesso e modificação
os passos necessários para chamar uma rotina e a própria rotina são partes do mesmo módulo
- precisamos simplificar os pontos de entrada do módulo (rotinas chamadas) de modo a evitar o zig-zag entre os módulos o que vai fazer com que fazer informações do funcionamento interno
- ex.: uma função que recebe apenas string mas a entrada atual é um inteiro, o módulo pode fornecer uma rotina para converter o o inteiro em string
- Nota pessoal: caso o módulo seja nível mais baixo e simples, onde performa apenas uma tarefa (converter, formatar, etc), pode valer a pena; em um módulo mais complexo e mais utilizado em que não sabemos o cliente (ex.: módulo de pagamento) talvez não vale a pena converter todo formato possível (vazando modelo do cliente), melhor fornecer um builder para facilitar a construção.

Reforços:

Ao aplicar a decomposição de módulos usando o ocultamento de informações nas regras contextualizadas possívelmente teremos um design com alta coesão e baixo acomplamento ao limitar o conhecimento entre os módulos apenas através dos pontos necessários.

Para analisar o acoplamento e coesão de um módulo basta olharmos seu motivo para alteração e os efeitos colaterais de fazê-la.

Próximos Passos

Ler as referências:

Neovim - Workflow para Java, C# e JS/TypeScript

Wesley Egberto — Sat, 29 Aug 2020 03:21:19 +0000

Neovim - Workflow para Java, C# e JS/TypeScript

Atualização 01/01/2023: como esse post usava a versão Neovim 0.4.x, escrevi um novo post com setup na versão Neovim 0.8 e LSP.

Background

Sou desenvolvedor especializado em Java e trabalho em projetos desenvolvidos em Java, C#, Javascript/TypeScript e Angular.

Introdução

Neovim é um projeto que, de acordo com o repositório no Github, busca refatorar agressivamente o Vim para que seja possível:

Simplificar manutenção e encorajar contribuição;
Dividir o trabalho entre múltiplos desenvolvedores;
Habilitar UI avançada sem modificações no core;
Maximizar extensibilidade.

A maior vantagem que percebi foi a comunidade provendo diversas interfaces e extensões que facilitam a transição de uma IDE para o Neovim.
Um exemplo de interface é o VimR.

Para introdução e motivação completa acesse a Wiki no Github.

Instalação

Para instalação basta seguir os passos descritos aqui onde são disponibilizados os pacotes e comandos para instalação em diversos SOs.

Todos os comandos do Vim funcionam normalmente no Neovim visto que é um fork da versão Vim 7.4.160 e que vem sendo atualizado constantemente.

Plugins

Alguns plugins que uso:

Vundle: gerenciar os plugins =), permite instalar/atualizar os plugins através da referência do github (ex.: Plug 'VundleVim/Vundle.vim'), vale a pena adicionar uma referência dele mesmo para permitir atualizações automáticas.
Fzf e Fzf.vim: plugin para permitir pesquisar arquivos no disco, texto, etc, igual ao famoso Ctrl+P do Sublime Text.
Vim-airline: plugin para exibir algumas informações no rodapé do painel (como branch, linguagem, tamanho do arquivo, etc).
Vim-numbertoggle: plugin para facilitar a navegação relativa com j e k.
Vim-easymotion: plugin para facilitar e acelerar a navegação no arquivo.
Vim-multiple-cursors: plugin para habilitar multiplos cursores igual ao Ctrl+D do VS Code.
Coc.nvim: plugin para habilitar intellisense com autocomplete, LSP e snippets, tudo de forma assíncrona e leve. Provê ótima extensibilidade com vários plugins para várias linguagens. Utilizo em Java, C# e Javascript/Typescript.
Vim-Syntastic: plugin para code checking e exibição do resultado no editor.
Omnisharp-vim: plugin para suporte do desenvolvimento completo em C#.

Workflow

O plugin Coc.nvim basicamente provê suporte para as principais linguagens que utilizo no dia-a-dia.
Para facilitar a experiência no Neovim e trazer aquele feeling de IDE utilizo as extensões abaixo:

coc-actions: implementa popups no Coc.nvim de forma que as sugestões de snippets, ações e contexto sejam mostradas no próprio cursor.
coc-explorer: explorador de arquivos leve e customizável, permitindo funcionar em um painel fixo ou popup.
coc-snippets: provê suporte para utilizar extensões de diversos plugins (UltiSnips, snipmate e até VSCode) com preview.

Também utilizo o antoinemadec/coc-fzf para exibir as ações do Coc.nvim em popups com Fzf que permite agilizar a visualização e ação necessária.

Para facilitar minha vida nas tarefas rápidas que faço pelo terminal (como docker, git, npm, etc) utilizo o vim-floaterm que permite executar diversas tarefas através de popups.

E alguns plugins para snippets:

ultisnips: provê suporte de snippets leve e rápido.
vim-snippets: disponibiliza diversos snippets para diversas linguagens.

Abaixo segue as combinações de plugins que utilizo para cada linguagem de forma que tenha sempre autocomplete, snippets, code checking e builds:

Java

Utilizo Coc.nvim com a extensão coc-java que instala o JDT do Eclipse que provê suporte completo igual ao Eclipse.
E utilizo o vim-syntastic que efetua o code checking de forma assíncrona.

Csharp

Utilizo os plugins Coc.nvim com a extensão coc-omnisharp e Omnisharp-vim.

Javascript/TypeScript

Utilizo o Coc.nvim com a extensão coc-tsserver.

Dotfiles

Além desses existem diversos outros plugins para facilitar navegação, edição e suporte de linguagens e highlight de sintaxes.

Para ver todos os plugins e configurações que utilizo até a escrita deste post, acesse meu Dotfiles no Github na branch para Neovim 0.4.

Angular - Introdução aos Testes

Wesley Egberto — Tue, 21 Apr 2020 02:15:22 +0000

Hoje iniciaremos uma série de posts sobre testes em Angular.

Outros posts da série:

Caso você não conheça ou seja novo em Angular recomendo uma das melhores video-aulas que existe em português ministradas pela Loiana Groner, veja aqui.

Angular nos fornece uma variedade de APIs para efetuarmos testes dos nossos componentes de forma fácil e rápida.

Quando criamos um projeto utilizando o Angular CLI executando o comando ng new já é configurado tudo que é preciso para testar um projeto Angular.

As ferramentas de testes utilizadas pelo Angular por padrão são:

Karma: test runner no browser;
Jasmine: framework para testes unitários e integrados, também fornece suporte para mocks.

Também é possível utilizar outras ferramentas como: Jest, Mocha/Chai, Sion, TestDouble, Wallaby, Cypress. Mas é necessário configuração manual.

Karma

Karma é um framework para rodar testes JavaScript que nos permite ser bastante produtivos ao prover um ambiente totalmente configurado (e que pode ser customizado) e um rápido feedback dos testes.

Jasmine

Jasmine é um framework BDD (behavior-driven development) para testes de código JavaScript. Ele não requer DOM para rodar e não possui nenhuma dependência.

Devido ao BDD e sua API fluente, sua sintaxe se torna bem limpa e extramente fácil de ler.

Nos fornece uma série de API para validar valores e objetos, efetuar testes unitários e integrados, criar mocks para nos ajudar a isolar nossos testes, etc.

O framework nos fornece uma série de APIs:

matchers: funções para validar valores e objetos;
funções setup: funções para preparar os objetos que usaremos nos testes (ex.: objeto que tenha inicialização seja muito complexa);
funções teardown: funções para fazer a limpeza ou pós-processamento dos objetos utilizados nos testes (ex.: limpar recursos compartilhados ou complexos em um testes integrado – banco de dados in-memory);
mocks: objetos dummy que podem ser configurados conforme o teste demandar.

Exemplo de Teste no Jasmine

A seguir temos um exemplo de estrutura de teste em Jasmine com os métodos estão comentados com a explicação de uso:

/**
 * A função `describe` define um conjunto de especificações que precisam
 * ser testadas.
 * No testes do Angular, geralmente, o cenário estará vinculado a uma
 * estrutura do Angular: um componente, service, pipe, etc.
 */
describe('Meu Cenario', () => {
    // system under test (unidade que será testada teste)
    let sut: any = null;

    /**
     * Função para configurarmos algo que será compartilhado
     * entre todos os testes.
     */
    beforeAll(() => {
        console.log('Roda apenas uma vez antes de todos os testes');
    });

    /**
     * Função para configurarmos os objetos que usaremos em cada teste.
     * É importante sempre iniciarlizar aqui para que sempre seja
     * resetado antes de cada teste, assim, evitando que um teste
     * influencie outro.
     */
    beforeEach(() => {
        console.log('Roda uma vez antes de cada teste');
        sut = {};
    });

    /**
     * Define uma especificação única que será testada, dentro de um cenário BDD
     * podemos ter vários testes (funções `it`) ou até mesmo outros cenários (funções `describe`).
     * BDD recomenta que os testes sempre iniciem com `deveria` (traduzido de `should`).
     */
    it('should be true if true', () => {
        // Montagem do cenário
        sut.a = false;
        // Ação
        sut.a = true;
        // Asserção
        expect(sut.a).toBe(true);
    });

    /**
     * Função para limparmos algo depois de cada teste.
     */
    afterEach(() => {
      console.log('Roda uma vez depois de cada teste');
    });

    /**
     * Função para limparmos algo compartilhado entre todos os testes.
     */
    afterAll(() => {
      console.log('Roda apenas uma vez depois de todos os testes');
    });
});

É importante ter o sufixo .spec.ts porque o runner fará uma pesquisa por ele.

Um teste deveria ser uma história completa contida na função it. Não deveria ser preciso ficar olhando ao redor para entender o teste.

Dicas:

mova código menos interessante de setup para dentro da função beforeEach;
mantenha o setup crítico dentro da especificação em teste (função it);
a especificação em teste (função it) deveria conter as três partes do teste: arranjo da pré-condição; ação e a asserção.

Tipos de Testes

Unit tests:
- Testa uma unidade de código (pode ser função, pipe, service, classe, componente);
- Tipos de testes unitários no Angular:
- Isolado: testamos uma única classe ou função onde instanciamos manualmente passando os argumentos necessários;
- Integrado: testamos uma unidade através da criação de um module do Angular (por exemplo, para testar o template de um componente), pode ser divido em:
  - Shallow: testamos apenas um componente (sem os filhos);
  - Deep: testamos o componente com os filhos.
Integration tests:
- Testa um conjunto de unidades de código que juntas entragam uma funcionalidade.
End to End (E2E) test:
- Aplicação live running;
- Utiliza um browser com açÕes automatizadas (webdriver).

Mocks

Mocks nos ajudam a garantir que estamos testando uma unidade de forma isolada.

Mock permite simular uma dependência que a unidade precisa para funcionar de forma completa.

Tipos de mock:

Dummies: objeto para ocupar uma dependência;
Stubs: objeto que tem um comportamento controlável, definimos nele o retorno necessário para completar o cenário que estamos testando;
Spies: objeto que rastreia quais métodos deles foram chamados, com quais argumentos e quantas vezes, usamos ele para garantir que o comportamento esperado da unidade está sendo executado;
True mocks: objeto que usamos para saber se foi utilizado de uma forma bem específica (se determinado método foi chamado, quais argumentos, quais não deveriam ser chamados, etc), são mais complexos de montar mas ajudam a garantir o comportamento esperado.

Angular Tests

No Angular, os arquivos de testes têm o mesmo nome da unidade (seja uma pipe, service, componente ou simples classe) que
estamos testando mas com o sufixo .spec.ts, e fica na mesma pasta da unidade que estamos testando.

Os testes isolados são bem diretos vistos que são apenas classes. Normalmente pipes, services e componentes terão uma estrutura de teste similar.
Às vezes um mock será necessário para ajudar a isolar a unidade.

Primeiro Teste

Dados a pipe abaixo:

// strength.pipe.ts
import { Pipe, PipeTransform } from '@angular/core';

@Pipe({ name: 'strength' })
export class StrengthPipe implements PipeTransform {
  transform(value: number): string {
    if(value < 10) {
      return value + " (weak)";
    } else if(value >= 10 && value < 20) {
      return value + " (strong)";
    } else {
      return value + " (unbelievable)";
    }
  }
}

Podemos escrever um teste abaixo:

// strength.pipe.spec.ts
import { StrengthPipe } from './strength.pipe';

// declaramos a especificação de teste da Pipe
describe('StrengthPipe', () => {
  let pipe: StrengthPipe;

  // prepara o objeto de teste
  beforeEach(() => {
    // instancia a Pipe que iremos testar
    pipe = new StrengthPipe();
  });

  it('should display weak if strength is 5', () => {
    expect(pipe.transform(5)).toBe('5 (weak)');
  });

  it('should display strong if strength is 10', () => {
    expect(pipe.transform(10)).toBe('10 (strong)');
  });
});

Em um projeto criado a partir do Angular CLI basta executarmos npm test pelo terminal para rodar os testes.

No próximo post criaremos alguns testes de componentes.

DEV Community: Wesley Egberto

Evolução do Switch no Java

Switch Statement

Switch Expression (Java 14+)

Switch Expression

Arrow Labels

Exhaustiveness

Pattern Matching para Switch (Java 17+)

Pattern Matching

Conclusão

Neovim - Workflow para Java, C# e JS/TypeScript (Atualização com Neovim 0.8 e LSP)

Introdução

Instalação

Plugins

Workflow

Dotfiles

Angular - Testes de Componentes

Introdução

Teste Unitário da Classe de Componente

Testando Componente

Testando Data Binding

Código do Componente

Teste da Classe do Componente

Teste do Binding do DOM

Configuração do Módulo de Teste

Testando o Estado e Interações com DOM

Karma e o DOM

Testando Formulário

Código do Componente e do Service

Testando o Formulário

Github Actions - Introdução com Java

Componentes

Workflows

Events

Job

Actions

Runner

Estrutura do Workflow

Componentes do Workflow

Primeiro Exemplo

Exemplo de Workflow Completo

Workflow

Conclusão

Referências

Spring Boot - Estratégias para testar Rest API

Spring Boot - Estratégias para testar Rest API

Inside-Server Test

MockMVC com Standalone-mode

MockMVC com Spring Context

Outside-Server Test

@SpringBootTest com MockMvc (sem webserver real)

@SpringBootTest com RestTemplate ou TestRestTemplate (com webserver real)

Nota

Angular - Testes de Pipes e Services

Pipes

Services

Service Sem Dependências

Service com Dependência

Service com HTTP Client

Maven - Resources Dinâmicos

Spring - Exception Handler

Tratamento Padrão

Tratamento Customizado

Usando @ResponseStatus

Usando @ExceptionHandler

Controller com @ExceptionHandler

Classe com ControllerAdvice e RestControllerAdvice

Exemplo

Notas:

Links:

Resumo do paper 'On The Criteria To Be Used In Decomposing Systems Into Modules' do Parnas

Problema

Módulos

Contribuição

Comparação

Método Proposto

Próximos Passos

Neovim - Workflow para Java, C# e JS/TypeScript

Neovim - Workflow para Java, C# e JS/TypeScript

Background

`@SpringBootTest` com MockMvc (sem webserver real)

`@SpringBootTest` com RestTemplate ou TestRestTemplate (com webserver real)