DEV Community: Adriana Ferreira Lima Shikasho

Olha que legal minha conversa com o ChatGPT sobre Polimorfismo no Javascript

Adriana Ferreira Lima Shikasho — Mon, 15 May 2023 23:31:52 +0000

🙋🏻‍♀️ Eu: - Me dê um exemplo de polimorfismo usando Javascript.

🤖 ChatGPT: - Claro! Aqui está um exemplo de polimorfismo em JavaScript:

// Classe base
class Animal {
  constructor(name) {
    this.name = name;
  }

  makeSound() {
    console.log("O animal faz um som.");
  }
}

// Subclasse que estende a classe Animal
class Dog extends Animal {
  makeSound() {
    console.log("O cachorro late.");
  }
}

// Subclasse que estende a classe Animal
class Cat extends Animal {
  makeSound() {
    console.log("O gato mia.");
  }
}

// Função que recebe um objeto Animal e chama o método makeSound
function makeAnimalSound(animal) {
  animal.makeSound();
}

// Criando instâncias das classes Dog e Cat
const dog = new Dog("Rex");
const cat = new Cat("Whiskers");

// Chamando a função makeAnimalSound com diferentes objetos
makeAnimalSound(dog); // Saída: "O cachorro late."
makeAnimalSound(cat); // Saída: "O gato mia."

Nesse exemplo, temos uma classe base chamada Animal com um método makeSound. Em seguida, temos duas subclasses, Dog (cachorro) e Cat (gato), que estendem a classe base Animal e substituem o método makeSound para produzir o som específico de cada animal.

A função makeAnimalSound recebe um objeto do tipo Animal (que pode ser uma instância de Dog ou Cat) e chama o método makeSound do objeto. Dependendo do tipo do objeto passado, o método makeSound apropriado será executado.

Isso é polimorfismo, onde diferentes objetos podem responder de maneira diferente ao mesmo método, permitindo um código mais flexível e reutilizável.

🙋🏻‍♀️ Eu: - É possível aplicar polimorfismo na programaçao funcional?

🤖 ChatGPT: - Na programação funcional, o conceito de polimorfismo é um pouco diferente do exemplo anterior, pois não há classes ou herança como na programação orientada a objetos.

No entanto, é possível obter um comportamento polimórfico usando funções de alta ordem (higher-order functions) e passando funções como parâmetros.

Aqui está uma adaptação do exemplo anterior para demonstrar o polimorfismo em programação funcional:

// Função polimórfica que recebe uma função como argumento
function makeAnimalSound(animalFn) {
  return animalFn();
}

// Funções específicas para diferentes sons de animais
function dogSound() {
  console.log("O cachorro late.");
}

function catSound() {
  console.log("O gato mia.");
}

// Utilizando a função polimórfica com diferentes funções
makeAnimalSound(dogSound); // Saída: "O cachorro late."
makeAnimalSound(catSound); // Saída: "O gato mia."

Neste exemplo, temos a função makeAnimalSound que recebe uma função como argumento (animalFn). Essa função é polimórfica, pois pode receber diferentes funções específicas para diferentes sons de animais.

As funções dogSound e catSound são exemplos de funções específicas para diferentes sons de animais. Cada uma dessas funções produz um som específico quando é chamada.

Ao chamar a função makeAnimalSound com diferentes funções (dogSound e catSound), obtemos resultados diferentes, cada um correspondendo ao som específico do animal.

Assim, conseguimos obter um comportamento polimórfico ao passar diferentes funções para a função makeAnimalSound na programação funcional.

🙋🏻‍♀️ Eu: - Podemos dizer então, que a classe é polimorfica quando recebe diferentes classes como argumento?

🤖 ChatGPT: - Sim, podemos dizer que uma classe é polimórfica quando ela recebe diferentes classes como argumento.

No contexto da programação orientada a objetos, o polimorfismo é alcançado por meio do conceito de herança e da capacidade de uma classe base tratar objetos de suas subclasses de maneira uniforme.

Quando uma classe base pode receber diferentes objetos de suas subclasses e chamar métodos com o mesmo nome, mas com implementações específicas em cada subclasse, dizemos que a classe base é polimórfica.

Vamos adaptar o exemplo do animal para ilustrar esse conceito:

// Classe base
class Animal {
  constructor(name) {
    this.name = name;
  }

  makeSound() {
    console.log("O animal faz um som.");
  }
}

// Subclasse que estende a classe Animal
class Dog extends Animal {
  makeSound() {
    console.log("O cachorro late.");
  }
}

// Subclasse que estende a classe Animal
class Cat extends Animal {
  makeSound() {
    console.log("O gato mia.");
  }
}

// Função que recebe um objeto Animal e chama o método makeSound
function makeAnimalSound(animal) {
  animal.makeSound();
}

// Criando instâncias das classes Dog e Cat
const dog = new Dog("Rex");
const cat = new Cat("Whiskers");

// Chamando a função makeAnimalSound com diferentes objetos
makeAnimalSound(dog); // Saída: "O cachorro late."
makeAnimalSound(cat); // Saída: "O gato mia."

Neste exemplo, a classe Animal é polimórfica, pois pode receber diferentes objetos de suas subclasses Dog e Cat.

A função makeAnimalSound recebe um objeto do tipo Animal como argumento e chama o método makeSound do objeto.

Quando chamamos a função makeAnimalSound passando um objeto dog, o método makeSound da classe Dog é executado, produzindo o som específico do cachorro.

Da mesma forma, quando passamos um objeto cat, o método makeSound da classe Cat é executado, produzindo o som específico do gato.

Dessa forma, a classe Animal é polimórfica porque pode tratar diferentes objetos de suas subclasses de maneira uniforme e executar o comportamento apropriado para cada subclasse.

🙋🏻‍♀️ Eu: - Por favor, me dê um exemplo usando uma classe Product

🤖 ChatGPT: - Claro! Aqui está um exemplo usando a classe Product (Produto) para ilustrar o polimorfismo:

// Classe base
class Product {
  constructor(name, price) {
    this.name = name;
    this.price = price;
  }

  calculateDiscount() {
    return 0; // sem desconto por padrão
  }
}

// Subclasse que estende a classe Product
class SaleProduct extends Product {
  constructor(name, price, discountPercentage) {
    super(name, price);
    this.discountPercentage = discountPercentage;
  }

  calculateDiscount() {
    return (this.price * this.discountPercentage) / 100;
  }
}

// Subclasse que estende a classe Product
class ClearanceProduct extends Product {
  constructor(name, price, clearancePrice) {
    super(name, price);
    this.clearancePrice = clearancePrice;
  }

  calculateDiscount() {
    return this.price - this.clearancePrice;
  }
}

// Função que recebe um objeto Product e calcula o desconto
function calculateProductDiscount(product) {
  const discount = product.calculateDiscount();
  console.log(`O desconto do produto ${product.name} é de ${discount} reais.`);
}

// Criando instâncias das classes SaleProduct e ClearanceProduct
const saleProduct = new SaleProduct("Camiseta", 50, 20); // 20% de desconto
const clearanceProduct = new ClearanceProduct("Calça", 100, 70); // preço de liquidação de 70 reais

// Chamando a função calculateProductDiscount com diferentes objetos
calculateProductDiscount(saleProduct); // Saída: "O desconto do produto Camiseta é de 10 reais."
calculateProductDiscount(clearanceProduct); // Saída: "O desconto do produto Calça é de 30 reais."

Nesse exemplo, temos uma classe base chamada Product com um método calculateDiscount, que retorna o desconto do produto (ou zero, se não houver desconto).

Em seguida, temos duas subclasses, SaleProduct (Produto em promoção) e ClearanceProduct (Produto em liquidação), que estendem a classe base Product e substituem o método calculateDiscount para calcular o desconto de acordo com as regras específicas de cada subclasse.

A função calculateProductDiscount recebe um objeto do tipo Product (que pode ser uma instância de SaleProduct ou ClearanceProduct) e chama o método calculateDiscount do objeto para obter o valor do desconto.

Ao criar instâncias das subclasses SaleProduct e ClearanceProduct e chamar a função calculateProductDiscount com essas instâncias, obtemos resultados diferentes, dependendo do tipo do objeto.

O método calculateDiscount apropriado é executado para cada subclasse, fornecendo o valor de desconto correto para cada produto.

Dessa forma, o exemplo ilustra o polimorfismo na classe Product, onde diferentes objetos podem responder ao mesmo método de maneira diferente, permitindo um código mais flexível e reutilizável.

🙋🏻‍♀️ Eu: - Me dê o mesmo exemplo usando functions

🤖 ChatGPT: - Claro! Aqui está um exemplo usando funções em vez de classes para ilustrar o polimorfismo:

// Função base
function calculateDiscount(product) {
  return 0; // sem desconto por padrão
}

// Função para calcular o desconto de um produto em promoção
function calculateSaleDiscount(product) {
  return (product.price * product.discountPercentage) / 100;
}

// Função para calcular o desconto de um produto em liquidação
function calculateClearanceDiscount(product) {
  return product.price - product.clearancePrice;
}

// Objeto representando um produto em promoção
const saleProduct = {
  name: "Camiseta",
  price: 50,
  discountPercentage: 20, // 20% de desconto
};

// Objeto representando um produto em liquidação
const clearanceProduct = {
  name: "Calça",
  price: 100,
  clearancePrice: 70, // preço de liquidação de 70 reais
};

// Função que recebe um objeto produto e uma função de desconto e calcula o desconto
function calculateProductDiscount(product, discountFunction) {
  const discount = discountFunction(product);
  console.log(`O desconto do produto ${product.name} é de ${discount} reais.`);
}

// Chamando a função calculateProductDiscount com diferentes objetos e funções de desconto
calculateProductDiscount(saleProduct, calculateSaleDiscount); // Saída: "O desconto do produto Camiseta é de 10 reais."
calculateProductDiscount(clearanceProduct, calculateClearanceDiscount); // Saída: "O desconto do produto Calça é de 30 reais."

Nesse exemplo, temos funções separadas para calcular o desconto de diferentes tipos de produtos. A função calculateDiscount é a função base que retorna o desconto padrão de zero.

As funções calculateSaleDiscount e calculateClearanceDiscount são exemplos de funções específicas para calcular descontos de produtos em promoção e em liquidação, respectivamente.

Em vez de usar classes, utilizamos objetos para representar os produtos em promoção e em liquidação.

A função calculateProductDiscount recebe um objeto de produto e uma função de desconto como argumentos. Ela chama a função de desconto passando o objeto de produto e retorna o valor do desconto.

Ao chamar a função calculateProductDiscount com diferentes objetos de produto e funções de desconto correspondentes, obtemos resultados diferentes, cada um correspondendo ao desconto específico do tipo de produto.

Dessa forma, conseguimos obter um comportamento polimórfico ao passar diferentes objetos de produto e funções de desconto para a função calculateProductDiscount.

Cada função de desconto é executada para o tipo de produto apropriado, fornecendo o valor de desconto correto.

🙋🏻‍♀️ Eu: - Polimorfismo de uma function tem a ver com abstração de código?

🤖 ChatGPT: - Sim, o polimorfismo em funções está relacionado à abstração de código. O polimorfismo permite tratar diferentes objetos ou tipos de dados de maneira uniforme, ocultando detalhes específicos de implementação e fornecendo uma interface abstrata para interagir com eles.

Ao utilizar o polimorfismo, podemos escrever código genérico que pode lidar com diferentes tipos de dados ou objetos, sem se preocupar com os detalhes específicos de cada um. Isso leva a um código mais flexível, modular e reutilizável.

Quando aplicamos o polimorfismo em funções, podemos passar diferentes objetos ou tipos de dados como argumentos para a mesma função, permitindo que a função opere de maneira polimórfica em cada um deles. A função pode tratar esses objetos ou tipos de dados de forma abstrata, chamando métodos comuns ou aplicando operações genéricas a eles.

Essa abstração de código oferecida pelo polimorfismo permite que você escreva funções genéricas que podem ser reutilizadas com diferentes objetos ou tipos de dados, promovendo uma melhor modularidade, flexibilidade e capacidade de extensão do código.

Portanto, o polimorfismo em funções desempenha um papel importante na abstração de código, permitindo que você escreva código mais genérico, modular e flexível, ao tratar diferentes objetos ou tipos de dados de forma uniforme.

🙋🏻‍♀️ Eu: - Por exemplo, em uma aplicação em React, recebemos produtos da api e precisamos converter seu preço (number) para o valor da moeda do país selecionado. Posso considerar essa function localeCurrency como uma function polimórfica?

🤖 ChatGPT: - Sim, você pode considerar a função localeCurrency nesse cenário como uma função polimórfica. O polimorfismo ocorre quando uma função pode operar em diferentes tipos de dados ou objetos de maneira uniforme.

No seu exemplo em uma aplicação React, a função localeCurrency recebe um número (preço) e converte esse valor para a moeda específica com base no país selecionado.

Essa função pode ser aplicada a diferentes produtos e realizar a conversão da moeda corretamente, independentemente do tipo de produto ou do valor do preço.

A função localeCurrency é polimórfica porque ela pode ser usada com diferentes números (preços) e fornecer a conversão adequada para cada um deles, independentemente do tipo específico do produto.

Ao utilizar a função localeCurrency em diferentes contextos, você está tratando diferentes objetos (produtos) de maneira uniforme, aplicando a mesma lógica de conversão de moeda a cada um deles.

Essa capacidade de tratar diferentes objetos de forma genérica e aplicar operações consistentes é uma característica fundamental do polimorfismo.

Portanto, nesse caso, a função localeCurrency pode ser considerada uma função polimórfica, pois opera em diferentes valores numéricos (preços) de maneira uniforme, fornecendo a conversão correta da moeda com base na língua selecionada.

[pt-BR] Problemas com pacotes do npm? Verdaccio pode ser a solução

Adriana Ferreira Lima Shikasho — Wed, 04 May 2022 20:10:01 +0000

Este é um conteúdo adaptado do vídeo Vienna.js, Introduction to Verdaccio, January 2019. Para mais informações, veja What is Verdaccio? | Verdaccio

Verdaccio é um registro de proxy npm privado e leve para pacotes NodeJs.

A configuração é muito fácil e é feita local por meio de um arquivo config.yaml, e permite modificar o comportamento padrão, ativar plugins e recursos externos.
É compatível com todos os gerenciadores de pacotes como npm, yarn ou pnpm.
Todos os pacotes que você publica são privados e acessíveis apenas com base em sua configuração.
Armazena em cache todas as dependências sob demanda e agiliza as instalações em redes locais ou privadas.

NPM Registry

O NPM Registry é uma coleção open source de pacotes NodeJS com registros públicos, usado por back-end e front-end developers. Esses pacotes podem ser baixados e instalados por meio dos gerenciadores de pacotes como: npm (npm Inc), yarn (Facebook, Google, Exponent, Tidle), pnpm (Zoltan Kochan). Não importa qual gerenciador utilizarmos para instalar os pacotes de Node, eles farão a mesma coisa: requisições para o NPM Registry.

Quando instalamos um pacote, esperamos receber apenas um pacote, certo? Mas a verdade é que quando instalamos um pacote, recebemos muito mais pacotes do que esperávamos.

No contexto de javascript, a quantidade de pacotes publicados passa de 100k e está crescendo a cada dia. Cory House, especialista em React e JavaScript, publicou em seu Twitter a seguinte afirmação: "[...] atualmente, 97% do código de aplicações web vem do npm. Apenas 3% do código foi você que escreveu.”

Ou seja, nós dependemos completamente do NPM registry e devemos levar isso a sério pois esse registro pode falhar - como já aconteceu em agosto de 2018, quando acidentalmente um funcionário da npm Inc apagou alguns pacotes.

Podemos listar outros problemas que podem acontecer ao depender do npm como: Latência e problemas de conexão, preço e segurança estão foras do nosso controle, e o desenvolvimento offline que possui diversas limitações.

Offline

O npm cria um cache mas não permite compartilhá-lo (a não ser que você crie um registro de proxy); não permite a utilização de alguns comandos CLI como publish e info; áreas de funcionamento isoladas por políticas de seguranças restritas em algumas empresas, sendo necessário contatar time de operaçoes para permissões.

Conexão

Internet com conexão lenta prejudicam a velocidade de download. Alguns pacotes podem ser corrompidos por bloqueios de firewall (China por exemplo), ou os planos de internet são bem limitados (Russia, pode cobrar 60 euros para enviar apenas 1 email).

Segurança

Confiar seu código a empresas terceiras; dados confidenciais podem ser vazados ao npm.

A solução do Verdaccio

Ter registros é essencial para escalar projetos novos, mas fontes privadas são privilégios caros para pequenos grupos ou start-ups. Verdaccio vem como uma solução acessível para todos os problemas que vimos até agora.

Sua instalação é muito fácil, basta instalar globalmente executando: npm install —global verdaccio@latest , e rodar sua CLI com o comando verdaccio. É possível utiliza-lo também com o docker. Alguns recursos do Verdaccio:

Registro Privado

Podemos desfrutar de todos os benefícios e controle do registro npm sem tornar o nosso código público, pois tudo é feito localmente. Além disso, se você quiser usar uma versão modificada de algum pacote de terceiros, poderá publicar sua versão localmente com o mesmo nome.

Proxy / Uplinks

As ferramentas do cliente só trabalham com um registro por vez, mas podemos associar todos os registros com um recurso de escopo do npm (~/.npmrc), como o exemplo abaixo:

registry=https://registry.npmjs.org
@mycompany:registry=http://verdaccio-domain:4873

Entretanto, dessa forma é difícil de manter e de certa forma insegura, porque uma vez que isso é publicado acidentalmente ao github, tokens podem ser compartilhados ao publico.

O Verdaccio é um aplicativo de servidor proxy npm que atua como intermediário entre o cliente e solicita um recurso ao servidor npm.

Se você usa vários registros em sua organização e precisa buscar pacotes de várias fontes em um único projeto, o Verddacio permite encadear vários registros e buscar em um único endpoint.

Uplinks é o recurso que o Verddacio tem para associar multiplos registros. Um pacote pode ser fetch por multiplos registros como fallback, se um falhar, você terá outro disponível.

Cache de pacotes

Cache consiste num monte de dependências organizadas por nome. Uma dependência, consiste num arquivo metadata com um monte de tarballs, que é a versão binária do pacote. O cache irá te cobrir quando a conexão com o registro falhar ou quando você tiver totalmente offline.

O armazenamento do verdaccio é sistema baseado em arquivos, mas você pode usar algo diferente se você deseja escalar, como por exemplo usar Amazon s3 bucket para utilizar o verdaccio em nuvem.

O caching é importante principalmente para Integração Contínua (CI), pois você quer evitar falhas por questões externas. Com cache podemos salvar largura de banda e reduzir tráfico externo, principalmente quando rodamos o CI na nuvem, pois cada megabyte custa dinheiro.

O verdaccio é super recomendado a ser utilizado entre o servidor de build e o registro externo.

Possui plugins

Pode-se utilizar plugins gratuitos com o verdaccio, como plugins de autenticação (gitlab, LDAP), plugins de armazenamento (AWS, GCP), e por ser uma aplicação express nodejs, você pode adicionar seus endpoints ou pode interceptar suas requisições com plugins de middleware (npm audit).

Interface de usuário na web

Podemos pesquisar e navegar por pacotes privados e verificar todos os metadados que o pacote oferece: regulamento, autor, últimas versões, dependências, etc

E2E Tests

Se você usa monorepo, é recomendado testar todos os pacotes antes de publicá-los.

Como instalar e configurar o verdaccio

Instale verdaccio globalmente:

$ yarn global add verdaccio

Rode verdaccio para criar o arquivo de configuração default config.yaml:

$ verdaccio

Abra o config.yaml no VSCode:

$ code ~/.config/verdaccio/config.yaml

Adicione o github no uplinks, e inclua seu token de acesso pessoal no auth.token:

uplinks:
  npmjs:
    url: https://registry.npmjs.org/
  github:
    url: https://npm.pkg.github.com/
    auth:
      type: bearer
      token: <GITHUB_PERSONAL_TOKEN>

Adicione os pacotes que deseja rodar localmente nos packages:

packages:
  '@belezanaweb/*':
    access: $all
    publish: $authenticated
    unpublish: $authenticated
    proxy: github

🙌🏼 Pronto! O verdaccio está configurado para ser utilizado!

[pt-BR] Terraform: Provisionamento de Nuvem com IaC - #3

Adriana Ferreira Lima Shikasho — Wed, 06 Apr 2022 15:39:01 +0000

Conhecendo o Terraform

Infrastructure as Code (IaC)
Configuração do Ambiente de Desenvolvimento
Comandos básicos do Terraform
Criação de Máquina Virtual + Apache Server (Iaas)
Variáveis no Terraform

Infrastructure as Code (IaC)

Em ambientes on-premises, a infraestrutura tem recursos físicos de hardware como servidores, máquinas, locação refrigerada e recursos humanos para instalar e configurar sistemas operacionais, ferramentas de desenvolvimento e fazer a manutenção das operações.

Em ambientes em nuvem, toda infraestrutura é virtualizada, ou seja, ainda existe um ambiente físico, mas sob total responsabilidade dos provedores de nuvem. O usuário consegue criar máquinas e servidores e conectar cabos por exemplo, tudo de maneira virtual, por meio de interface ou por meio de código.

Pela interface, é necessário entrar na conta do provedor para criar e gerenciar seus recursos, como por exemplo na plataforma da Azure.

Por código, pode-se utilizar orquestradores de nuvem, como por exemplo o Terraform, que permite gerenciar os recursos por meio da escrita de scripts em um formato parecido com JSON ou YML. Essa forma de fazer infraestrutura é o que se chama de Infrastructure as Code (IaC), ou seja, gerenciar infraestrutura por meio de código.

Configuração do Ambiente de Desenvolvimento

Para fazer IaC, precisamos configurar o ambiente de desenvolvimento. Escolhemos a Azure como provedor de nuvem e o Terraform como gerenciador de Nuvem. O ambiente de desenvolvimento é bem simples e requer apenas 3 passos:

Criar conta na Azure
Instalar AZ CLI
Instalar Terraform

Obs: Existem ferramentas que também nos auxiliam na criação do ambiente para desenvolvimento de nuvem, como o Vagrant, mas aqui vamos começar de forma mais simples apenas para conhecer o Azure e o Terraform.

Comandos básicos do Terraform

Criar uma pasta para o projeto e executar terraform init
Criar um arquivo main.tf para escrever o script com toda a descrição de infra
Executar terraform validatepara verificar se a sintaxe do script está correta
Executar terraform plan para rever o que será executado no script (diff)
Executar terraform applypara subir e rodar o script na nuvem
Para excluir tudo da nuvem, executar terraform destroy

Criação de Máquina Virtual + servidor Apache na Azure

Na Azure, os hadwares, softwares e ferramentas disponíveis para infraestrutura são chamados de Recursos.
Para criar uma máquina virtual + Apache server, é necessário criar um Resource Group que vai agrupar os seguintes recursos:

Recursos relacionados à rede:
- Virtual Network
- IP Público
- Firewall
- Placa de Rede
- Sub-Rede
Recursos relacionados à Máquina Virtual
- Conta de Armazenamento
- Máquina Virtual
Recursos relacionadas a Deploy
- Executor de script

Em todos os provedores de nuvem, os recursos são os mesmos, mas podem ter nomes e características diferentes. Vamos conhecer os recursos da Azure necessários para criar uma máquina virtual com servidor Apache.

Resource Group

azurerm_resource_group

O Resource Group (Grupo de Recursos) tem como finalidade agrupar os recursos do Azure com um objetivo específico.
Esse agrupamento permite o administrador realizar a criação, monitoramento, controle de acessos e de custo de cada grupo de recursos.

Virtual Network (vnet)

azurerm_virtual_network

A rede virtual permite a comunicação entre várias máquinas virtuais em diferentes locais pela internet por meio de softwares (diferente da rede física que utiliza cabeamento e hardwares). Esses softwares são versões virtualizadas de ferramentas de rede tradicionais, como switches e adaptadores de rede, permitindo roteamento mais eficiente e alterações de configuração de rede mais fáceis.

SubNet

azurerm_subnet

As sub-redes representam segmentos de rede dentro do espaço IP definido pela rede virtual. A subdivisão de uma rede grande em redes menores resulta num tráfego de rede reduzido, administração simplificada e melhor performance de rede

Public IP

azurerm_public_ip

Um endereço público significa que ele pode ser acessado pela Internet. Em redes compartilhadas, os dispositivos conectados podem ter endereços IP privados próprios, mas quando se conectam pela conexão de Internet, são convertidos em um endereço IP público atribuído ao roteador.

Network Security Group (NSG)

azurerm_network_security_group

Basicamente uma NSG é um Firewall (lógico) de rede, sua função é filtrar todo o tráfego direcionado a um recurso por meio de regras de segurança, e tomar as devidas ações. Controla a permissão de tráfego de rede de entrada ou de saída em relação a vários tipos de recursos do Azure. Para cada regra, você pode especificar origem e destino, porta e protocolo.

Network Interface (NIC)

azurerm_network_interface

A placa de interface de rede (NIC) é atribuída com o endereço IP e associada às regras NSG, que são usadas para a comunicação entre a máquina virtual ou a rede interna ou a Internet.

Network Interface Security Group Association (NIC-NSG)

azurerm_network_interface_security_group_association

Um recurso apenas para conectar um Network Security Group (NSG) a uma interface de rede (NIC).

Storage Account (SA)

azurerm_storage_account

Uma conta de armazenamento do Azure contém todos os seus objetos de dados do Armazenamento do Azure, incluindo blobs, compartilhamentos de arquivos, filas, tabelas e discos. A conta de armazenamento fornece um namespace exclusivo para seus dados de armazenamento do Azure que podem ser acessados de qualquer lugar do mundo por HTTP ou HTTPS.

Virtual Machine (VM)

azurerm_virtual_machine

As Máquinas Virtuais do Azure (VM) são um dos vários tipos de recursos de computação escalonáveis sob demanda que o Azure oferece. Normalmente, você escolhe uma VM quando precisa de mais controle sobre o ambiente de computação do que as outras opções oferecem.

Para verificar o tamanho das máquinas disponíveis na Azure, ver aqui.

null_resource

O null_resource é um recurso que permite configurar 3 provisionadores que não estão diretamente associados a um recurso existente. Se comporta exatamente como qualquer outro recurso, portanto, você configura provisionadores, detalhes de conexão e outros metaparâmetros da mesma maneira que faria em qualquer outro recurso.

Os 3 tipos de provisionadores (provisioner) são:

file: faz upload de arquivo/pasta (com aplicação) para a VM
remote-exec: executa um script na VM
local-exec: executa um script na minha máquina local

Com remote-exec pode-se executar scripts na VM, ou seja, podemos instalar o apache ou qualquer outra coisa na máquina. Abaixo é a configuração de instalação do servidor Apache

resource "null_resource" "install-apache" {
  connection {
    type     = "ssh"
    host     = data.azurerm_public_ip.var_publicip.ip_address
    user     = var.user
    password = var.password
  }
  # remote-exec executa um script na VM
  provisioner "remote-exec" {
    inline = [
      "sudo apt update",
      "sudo apt install -y apache2",
    ]
  }
  # Indica que esse null_resource depende da criação da VM
  depends_on = [azurerm_virtual_machine.atividade-infra-vm]

Obs: Para usar o null_resource, precisa rodar o terraform init novamente, para baixar este plugin.

Variáveis no Terraform

Existem várias formas de informar os valores das variáveis que usamos no script do Terraform:

Na execução do terraform

No momento de execução do terraform plano terminal vai solicitar a inclusão dos valores das variáveis que foram declaradas

Arquivo de variáveis

Criar um arquivo "terraform.tfvars" não-versionado na raíz do projeto com a declaraçao das variáveis e seus valores

  // terraform.tfvars
  user     = "admin"
  password = "Password123456!"

Variável Ambiente Local

Criar variável ambiente na máquina local (Linux):

  export TF_VAR_USER="admin"
  export TF_VAR_PWD="Password123456!"

Para verificar a variável criada, executar:

  echo $TF_VAR_USER

Gerenciador de Senhas

O gerenciador de senhas protege, armazena e controla rigidamente o acesso a tokens, senhas, certificados, chaves de criptografia para proteger segredos e outros dados confidenciais usando uma interface do usuário, CLI ou API HTTP.

Exemplos:

Vault da Hashcorp
Key Vault da Azure

[pt-BR] Migração e Implementação de Cloud - #2

Adriana Ferreira Lima Shikasho — Fri, 25 Mar 2022 22:54:20 +0000

Agora que já conhecemos a cultura devOps, as vantagens da computação em nuvem em relação ao ambiente on-premise e vimos um pouco dos modelos de serviços em nuvem - Iaas, Saas e Paas - vamos aprender mais 3 tópicos referentes a cloud:

Migração para serviços de Cloud:
- Re-host
- Re-platform
- Re-factor
- Re-purchase
- Retire
- Retain
Modelos de Implantação de Cloud:
- Nuvem Pública
- Nuvem Privada
- Nuvem Híbrida
Ambientes Single-Cloud X Multi-Cloud

Esse conteúdo foi baseado na Aula 1 de Infraestructure e Cloud Computing da pós-graduação de MBA em Desenvolvimento FullStack da Impacta.

1. Migração para serviços de Cloud

Vamos usar como exemplo a Amazon que com a AWS se tornou o primeiro player de nuvem do mercado. A AWS presta consultoria para que clientes migrem seus sistemas para a nuvem oferecendo 6 tipos de migração, também chamados de Jornada de Cloud:

Re-host

Ambiente Iaas. É a porta de entrada para o ambiente em nuvem, tecnicamente a migração mais simples pois do jeito que está no ambiente on-premise vai pra nuvem.

Por exemplo, as mesmas 5 máquinas virtuais vao ser colocadas no ambiente em nuvem, testadas, ver se tudo está funcionando e pronto. Não se aproveita todo o desempenho da nuvem pois foi feita uma migração bem básica.

As aplicações que rodam no ambiente que sofreram re-host são classificadas como Cloud Enabled, pois não foram feitas para rodar em nuvem, mas foram portadas para um ambiente em nuvem.

Re-platform

Ambiente Iaas + Paas. É o segundo step caso a empresa esteja interessada em trazer mais recursos para a nuvem. Ou seja, além das máquinas virtuais estarem na AWS, agora a empresa contrata algumas ferramentas para processamento, rede, desenvolvimento, banco de dados, etc e outros serviços.

As aplicações que sofreram re-platform são classificadas como Cloud Based, pois houveram modificações no sistema feito fora da nuvem, para rodar em nuvem.

Re-factor

Ambiente Iaas + Paas + Saas. Quando não vale a pena migrar um ou mais sistemas já existentes da empresa, então são feitos novos sistemas já seguindo o modelo em nuvem (Microserviços, Conteinerização, Serveless). É a migração mais complexa e permite o uso e nuvem em sua total capacidade.

As aplicações que sofreram re-factor são classificadas como Cloud Native pois foram feitas para o ambiente em nuvem.

Re-purchase

Quando não vale a pena migrar os sistemas já existentes na empresa, e também não serão desenvolvidos novos sistemas, então a empresa compra sistemas Saas por exemplo do provedor de nuvem.

Retire

Quando determinado sistema não vai migrar para nuvem e não será mais utilizado, é a aposentadoria do sistema, ele não é mais útil para a empresa.

Retain

Quando determinado sistema não vai ser migrado para a nuvem, e fica no ambiente on-premise.

2. Modelos de Implantação de Nuvem

Quando uma empresa planeja sua estratégia de cloud, ela pode optar por 3 modelos de implantação, sendo Nuvem Pública, Nuvem Privada e Nuvem Híbrida.

Como sempre, cada modelo tem vantagens e desvantagens, e a escolha depende muito da estratégia da empresa. Vamos ver um pouco de cada um desses modelos.

Nuvem Pública

Atualmente, o modelo de nuvem pública é a maneira mais comum de implantar a computação em nuvem, sendo o mais utilizado por empresas do mundo todo.

O provedor tem servidores próprios para alocar dados, softwares e sistemas de forma independente e isolada.

A Nuvem pública é basicamente uma nuvem aberta para qualquer pessoa ou empresa. AWS, GCP, Azure são alguns exemplos de provedores de nuvem pública.

Nuvem Privada

É basicamente um ambiente em nuvem oferecido por algum provedor, mas sua instalação é feita dentro do servidor on-premise da empresa.

Cada empresa pode personalizar seus recursos de modo a atender suas necessidades específicas, utilizando seus próprios hardwares.

As nuvens privadas geralmente são usadas por órgãos governamentais, instituições financeiras e outras organizações de grande porte com operações críticas para os negócios, que buscam melhorar o controle sobre seu ambiente.

Entretanto, esse é um serviço que aos poucos está sendo descontinuado por acabar trazendo mais problemas do que benefícios. Por exemplo, a elasticidade e região da nuvem privada pode ser limitada ao tamanho e localização única do data center da empresa.

Nuvem Híbrida

A nuvem híbrida mescla os outros dois modelos, tendo características tanto da nuvem pública quanto da privada. Isso permite que as empresas aproveitem as vantagens das duas opções ao mesmo tempo.

Para saber mais detalhes sobre os modelos de implantação, o site da Azure tem um bom resumo. Veja aqui.

3. Ambientes Single-Cloud X Multi-Cloud

Um ambiente único de Cloud (Single-Cloud) se caracteriza pela utilização de um único provedor para todos os serviços e aplicações da sua organização.

Em contrapartida, um ambiente Multicloud é aquele em que a empresa usa os serviços de vários provedores de nuvem.

O Multicloud é o mais indicado para evitar o "vendor lock-in" (aprisionamento tecnológico), que é uma forma do provedor manter o cliente "aprisionado" e dependente de determinada particularidade em produtos, e os impede de trocar de fornecedor sem custos adicionais substanciais.

Boas práticas para evitar o Vendor Lock-in

Tecnologias open-source
Conteinerização
Portabilidade e interoperabilidade
Infraestrutura como código
Plano estratégico para migração
Ambiente multicloud
Treinamento interno

Continua na parte 3 👉🏼 clique aqui

Referências:
https://www.softwareone.com/pt-br/blog/artigos/2020/01/22/multicloud-softwareone

https://azure.microsoft.com/pt-br/overview/what-are-private-public-hybrid-clouds/#overview

https://pt.wikipedia.org/wiki/Aprisionamento_tecnol%C3%B3gico

[pt-BR] DevOps e Computação em Nuvem - #1

Adriana Ferreira Lima Shikasho — Fri, 25 Mar 2022 22:28:25 +0000

Neste artigo, vamos conhecer a cultura DevOps e falar rapidamente sobre os benefícios que ela oferece para o desenvolvimento de software.

Além, disso, vamos aprender o que é a Computação em Nuvem e conhecer os modelos de serviços Iaas, Paas e Saas oferecidos pelos provedores de cloud do mercado.

Cultura DevOps
- A vantagem do DevOps
- 4 bases do DevOps
Cloud Computing
- Modelos de serviços de Nuvem

Esse conteúdo foi baseado na Aula 1 de Infraestructure e Cloud Computing da pós-graduação de MBA em Desenvolvimento FullStack da Impacta.

1. Cultura DevOps

Esse é mais um dos assuntos do mundo de TI que demonstra o quanto desenvolvedores não podem ser apenas máquinas de escrever códigos.

Um dev que conhece pelo menos um pouco de arquitetura, infraestrutura, engenharia e hardware está sempre um passo a frente daquele que só pensa em linguagem.

Quanto mais a gente se abre para conhecer o que está além do código, mais adquirimos habilidades e repertório para desenvolver com qualidade e segurança.

Não é necessário ser especialista em todos os assuntos, mas é importante conhecer e aprender um pouco das responsabilidades de outras frentes.

Mesmo não sendo nossa área de especialização, aprender do outro nos movimenta a agir com mais empatia.

E é aí que podemos encaixar a cultura DevOps, que vem de certa forma para ajudar a resolver possíveis atritos entre as diversas camadas do mundo de TI com métodos, ferramentas e dialogando muito bem com a cultura ágil.

A vantagem do DevOps

Vamos imaginar uma empresa que decide construir seu próprio Data Center. Para isso, precisou montar um bom espaço físico com sistema de refrigeração especializado, comprar vários servidores, hardwares de storage e rede, etc.

Esta empresa ainda vai precisar contratar diversas pessoas para criar times responsáveis por manter e gerenciar toda essa infraestrutura física, como passar cabos, monitorar servidores, configurar redes.

Além disso precisará de uma operação constante para atender demandas dos desenvolvedores como por exemplo criar servidores, subir aplicações, configurar máquinas e etc.

Esses desenvolvedores tem seu próprio prazo a cumprir, assim como as operações e as demais áreas.

Se nenhuma metodologia for implementada, esse processo que demanda muito tempo e recursos entre as operações pode até causar atritos entre as equipes, e trazer diversos tipos de prejuízos em vários níveis.

A cultura DevOps vem então para ajudar a resolver esse atrito e, de maneira mais simples, seu objetivo é remover as barreiras entre as duas equipes tradicionalmente separadas em silos: devs e operações.

Essa cultura traz métodos e ferramentas de modo a auxiliar as partes a trabalharem de forma linear, ágil e harmonizada, encurtando o intervalo entre a idealização do projeto e a entrega.

É necessário uma mudança de mentalidade, entretanto, a longo prazo, deve-se verificar um aumento a eficiência na comunicação e integração entre as equipes de modo a otimizar a produtividade dos desenvolvedores e a confiabilidade das operações.

4 bases do DevOps

De maneira prática, podemos separar o devOps em 4 bases, que conversam com o ciclo de vida do desenvolvimento de software. Vamos ver um pouquinho de cada uma dessas etapas.

Agile Development

Etapa de desenvolvimento de forma iterativa e incremental com métodos ágeis. É a fase que requisitos, produto, backlogs, desenvolvimento, que usam os frameworks de trabalho como Scrum, Kanbam, etc.

Continuous Integration (CI)

Etapa de junção do código produzido e avaliação da qualidade do repositório. Cada componente da equipe entrega uma parte do código e é preciso depois juntar tudo e trabalhar na consistência dele, utilizar métodos e ferramentas para avaliar se está bom, se funciona, se compila. Exemplos de ferramentas: Jenkins, Azure DevOps, CodePipeline, etc.

Continuous Testing (CT)

Etapa de testes automatizados, como este de unidade, integraçao, aceitação para validar se aquilo que estamos levando para o usuário tem qualidade. Tem um casamento perfeito com a CI, o código está sendo compilado e testado o tempo todo. Exemplos de ferramentas: JUnit, Selenium, Appium, JMeter, etc.

Continuos Delivery (CD)

É essa etapa que diz respeito a infraestrutura, que leva a aplicação a um ambiente (homol, prod). São utilizadas ferramentas e métodos para facilitar e trazer conforto a gestão da infra, como Infraestructure as code (IaC), Ferramentas de provisionamento e Gestão de Repositórios. Exemplos de ferramentas: Terraform, Ansible, Docker, Kubernetes, Vagrant, etc.

2. Cloud Computing

Clouding Computing é a prática desse processo que traz agilidade e redução e custo no provisionamento de infraestrutura e operação.

Quando falamos de nuvem, falamos de um conforto e facilidade para gerenciar a infraestrutura, que demanda menos tempo, menos recursos humanos e traz cada vez mais segurança ao ciclo de vida dos sistemas.

O IaC acaba sendo um processo que abstrai a infraestrutura, traz escabilidade conforme demanda, e controla a tolerância a falhas. Um exemplo prático do IaC, é escrever um arquivo, como se fosse uma receita de bolo. Por exemplo:

Preciso ter 2 servidores com comunicação TCP
- O servidor 1
  - é de aplicação web
  - tem acesso a internet
  - tem phyton
- O servidor 2
  - é de banco de dados
  - mySQL na versão tal
  - etc

Obviamente que na vida real não será escrito desta forma, mas esse é um exemplo do quão fácil seria configurar alguns servidores ao utilizar o desenvolvimento em nuvem. Agora conseguimos criar uma série de automações que não eram possíveis no passado.

Modelos de serviços de Nuvem

O provedores de nuvem mais conhecidos e utilizados hoje em dia são Azure, AWS e Google Cloud Platform, e cada um tem seus próprios serviços, pacotes e consultorias.

Entretanto, podemos elencar 3 modelos de serviços que encontramos em todos eles: Iaas, Saas e Paas.

Mas antes de conhece-los, vamos começar com uma analogia para ilustrar o modelo tradicional e nos dar base para entender os modelos em nuvem.

On-premise

Vamos imaginar um cenário da compra de um carro próprio. Antes mesmo de começar a dirigir, é necessário que a pessoa tire carta, pague o IPVA, faça seguro, realize manutenção constante, coloque gasolina, etc. Ou seja, é preciso muito recurso e muito esforço antes mesmo de comprar o carro, e durante o uso desse transporte.

Da mesma forma é quando a empresa tem o próprio data center, chamado de ambiente on-premise. É necessário desembolsar uma super grana para comprar servidor, para montar uma estrutura de refrigeração com ar-condicionado, sobrepiso, etc.

Além disso, a empresa precisa de gente que saiba passar cabo, verificar energia elétrica, subir software, virtualizador, instalar java, python, msql dentro de uma máquina virtual.

Entretanto, esse modelo é o que traz mais autonomia para a empresa, pois ela pode fazer o que quiser já que todos os recursos são próprios.

Em seguida veremos os modelos de serviços de nuvem existentes, e quando mais a gente avança, menos autonomia a empresa vai ter ao contratar o serviço.

Iaas (Infraestructue as a Service)

O modelo Iaas é a porta de entrada para o serviço de nuvem e é como se fosse um carro por assinatura onde não é necessário comprar o carro, mas pagar um valor mensal que já consta o uso do carro, IPVA, seguro, etc.

A empresa recebe máquinas virtuais e a única coisa que precisará se preocupar é em colocar ferramentas e softwares lá dentro.

Da máquina virtual pra baixo, aqueles requisitos de data center como infraestrutura, refrigeração ou cabeamento fica por responsabilidade do serviço de nuvem contratado.

Responsabilidade do serviço de nuvem: data center + máquinas virtuais
Responsabilidade do cliente: receber as máquinas virtuais, fazer toda a instalação e gestão de ferramentas e usá-las para desenvolver os softwares

Paas (Platform as a Service)

O modelo Paas é como se fosse um taxi. Não é necessário se preocupar se tem gasolina, se tem seguro ou em pagar o IPVA, a única preocupação é informar o trajeto. Mas o carro não é próprio, então há menos liberdade.

O Paas é quando o serviço de nuvem me entrega uma ferramenta como serviço. Como por exemplo, o ambiente para eu rodar meu java, um banco de dados já instalado e pronto para ser utilizado.

Responsabilidade do serviço de nuvem: data center + máquinas virtuais + ferramentas
Responsabilidade do cliente: usar as ferramentas para desenvolver os softwares

Saas (Software as a Service)

O modelo Saas é como se fosse um ônibus. Assim como o taxi, não é necessário se preocupar com gasolina, IPVA ou seguro, entretanto, o ônibus não muda seu percurso pela demanda. É mais barato, mas há ainda menos liberdade.

O Saas entrega software pronto para funcionar como serviço, como por exemplo Gmail, Google Meeting, Google Classroom. Não há controle nenhum sobre as features do software e nenhum tipo de personalização.

Esse modelo também é multitenant (permite multilocação), ou seja, vários clientes podem ser acomodadas no mesmo servidor, mas cada um recebe seu próprio serviço e isolado.

Responsabilidade do serviço de nuvem: data center + máquinas virtuais + ferramentas + software
Responsabilidade do cliente: utilizar os softwares

Continua na parte 2 👉🏼 clique aqui

Referências:
https://csrc.nist.gov/publications/detail/sp/800-145/final
https://br.pinterest.com/pin/766737905309531976/?mt=login

[pt-BR] Como Testar Consumo de API de uma Aplicação em React - #4

Adriana Ferreira Lima Shikasho — Mon, 21 Feb 2022 21:20:58 +0000

Já testamos um componente Button, um componente Link que tem evento de usuário, um hook que armazena o estado dos produtos e permite adição de itens no carrinho. Ufa, já vimos bastante coisa por aqui, não é?

Agora, chegou a hora de testar se nossa aplicação faz a chamada à API da lista de produtos da loja e exibe o resultado na tela conforme o esperado.

Se você não viu ainda como testar componentes e como testar hooks, recomendo ler a parte 2 e parte 3 deste material antes de prosseguir.

O que será abordado:

Testando consumo de API
Conclusão

Testando consumo de API

Como sempre, vamos analisar o código do componente ProductsList. No useEffectsem dependência, vemos que ele já executa a chamada a API 1x ao carregamento do componente e em seguida, monta o componente listando os products que foi atualizado pela ação setProducts disponíbilizada pelo hook useCart.

import React, { useEffect, useState } from 'react';
import api from '../../../services/api';
import Product from '../../../models/Product';
import * as Molecules from '../../Molecules';
import { Container, Title, List } from './styles';

export default function ProductsList() {
  const [products, setProduts] = useState<Product[]>([]);

  useEffect(() => {
    const getProducts = async () => {
      const response = await api.get('/products');
      setProduts(response.data);
    };
    getProducts();
  }, []);

  return (
    <Container>
      <Title>Nossos Produtos</Title>
      <List>
        {products.map(item => (
          <Molecules.ProductItem key={item.id} product={item} />
        ))}
      </List>
    </Container>
  );
};

Pensar em consumo de API e em lidar com dados pode assustar um pouco, mas lembra que eu falei que nos testes tudo é simulado ou "mockado"?

Pois é, aqui também "mockaremos" os resultado da chamada a API, ou seja, os dados serão apenas um objeto que nós mesmos montaremos em uma variável cartProductMock.

A para simular também uma chamada à API, utilizaremos uma feature de uma lib chamada axios-mock-adapter, da qual permite essa simulação de um request utilizando o axios. (Você deve instalá-la como dependência usando npm ou yarn, ok?)

Beleza, vamos ver como isso funciona:

import React from 'react';
import MockAdapter from 'axios-mock-adapter';
import { render, act, waitFor } from '@testing-library/react';
import api from '../../../services/api';

import ProductsList from '.';
import cartProductMock from '../../../mocks/cartProductMock';

const apiMock = new MockAdapter(api);

describe('ProductsList component tests', () => {
  test('renders without crashing with request', async () => {
    act(() => {
      apiMock.onGet('/products')
      .reply(200, [{ ...cartProductMock }]);
    });

    const { getByText } = render(<ProductsList />);

    await waitFor(() => {
      expect(getByText('Test')).toBeInTheDocument();
    });
  });
});

Uau, a maioria dos métodos a gente já conhece!

Podemos ver que temos o act que simula uma ação, neste caso utilizando um método onGet do apiMock. Temos o getByText, que já vimos várias vezes e no fim qual o resultado esperado, que como a maioria das vezes é que ele esteja na tela sendo exibido corretamente.

Conclusão

Eu particularmente não acho testes algo muito fácil, pois pensando que são a garantia do funcionamento da aplicação que desenvolvemos, acaba sendo um processo que requer muita responsabildiade, principalmente para evitar falso positivos ou negativos.

Entretanto, saber que temos um recurso a mais que agrega confiabilidade ao nosso código e traz mais qualidade à aplicação é um tanto satisfatório, pois como devs sempre queremos buscamos nos aprimorar para cada vez fazer entregas melhores.

Estudar e me desenvolver em testes para front-end tem sido meu objetivo atual, e esse foi meu primeiro estudo de testes, da qual abriu muito a minha mente e tenho certeza que é o primeiro passo de uma longa jornada de aprendizado.

Obrigada por chegar até aqui, e caso esse conteúdo tenha sido relevante para você, não esqueça de deixar seu comentário ou compartilhar para que mais gente também possa aprender!

Referências:

Esse conteúdo foi baseado no vídeo “Treinamento: Como implementar testes unitários em React utilizando Jest” do canal da Zappts, feito pelo Cláudio Castro.

Confira o repositório com o projeto: https://github.com/ccastrojr/react_unit_test

[pt-BR] Como Testar Hooks de uma Aplicação em React - #3

Adriana Ferreira Lima Shikasho — Mon, 21 Feb 2022 16:48:31 +0000

Testes de hooks é algo que assusta muita gente, mas vamos tornar tudo mais simples a partir de agora!

Vamos continuar implementando testes na nossa aplicação de carrinho de ecommerce. Caso você não tenha visto o início dessa parte mais prática, confira na parte 2 deste material.

O que será abordado:

Testando Hooks
Simulação e mocks
Testando ações
Testando um Componente que utiliza um Hook

Testando Hooks

O hook deste carrinho possui um contexto que nos fornece as ações de listar produtos, adicionar e remover os itens do carrinho e calcular o valor total dos itens.

A ideia é criar pelo menos 1 teste para cada ação, e utilizar os estados fornecidos pelo contexto para adicionar os mocks. Vamos ver o código do contexto (Vou deixar comentado em código o que cada parte faz):

[...]

function CartProvider({ children }) {

// Estado que armazena os produtos
const [products, setProducts] = useState<CartItem[]>(() => {
    // pega os items em local storage
    const itemsStorage = localStorage.getItem('@UnitTest:cart');
    // se tiver items, retorna o valor como estado inicial
    if (itemsStorage) return JSON.parse(itemsStorage);
    // Se não tiver, retorna e inicia vazio.
    return [];
  });

  // Atualiza Local Storage com um novo array de itens
  useEffect(() => {
     localStorage.setItem('@UnitTest:cart', 
     JSON.stringify(products: CartItem[]));
  }, [products]);

// Ação que adiciona um item no carrinho
 const addToCart = useCallback(
     // Verifica se esse produto já existe no carrinho
     (item: Product) => {
     const productReceived = products.find(
        product => product.id === item.id
     );

     // Se sim, adiciona 1 na contagem do item existente
     if (!!productReceived) {
       productReceived.count += 1;
       setProducts([...products]);
     }

     // Se não, inclui o item no array com 1 no contador.
     else {
       setProducts([...products, { ...item, count: 1 }]);
     }
    },
 [products],
 );

[...]

Simulações e mocks

Certo! Agora, vamos implementar o primeiro teste deste hook que será a funcionalidade de pegar os itens que estão salvos em Local Storage.

Lembrando que esses items são armazenados no estado products, então o que esperamos neste teste, é que o e estado products tenha um array com algum item adicionado.

Esse teste vai se chamar getItems from LocalStorage. O código abaixo descreve esse teste, e você pode perceber que ele segue o mesmo padrão de escrita de testes que já aprendemos.

import React from 'react';
import { renderHook } from '@testing-library/react-hooks';
import { waitFor, act } from '@testing-library/react';

import { CartProvider, useCart } from '.';

describe('Cart hook tests', () => {
  test('get items from localStorage', async () => {

    // 1. renderizar o hook
    const { result } = renderHook(() => useCart(), {
      wrapper: CartProvider
    });

    // 2. fazer uma query ou mock
    const itemAddedToCart = {
      id: 1,
      createdAt: 'some_value',
      name: 'Product Test',
      price: 90,
      image: 'image_path',
      stock: 9,
    };

    // 3. executar alguma ação
    jest.spyOn(Storage.prototype,'getItem')
    .mockImplementation(key => {
      switch (key) {
        case '@ReactUnitTest:cart':
          return JSON.stringify([itemAddedToCart]);
        default:
          return null;
      }
    });

    // 4. descrever o resultado esperado
    await waitFor(() => {
      expect(result.current.products[0].name)
      .toEqual('Product Test');
    });
  });
});

renderHook: como hook não é um componente, utilizamos esse método para renderizar o Hook e conseguir pegar o resultado dele. Neste caso, importamos o useCart e o envolvemos pelo seu provider o CartProvider.

result: pega o resultado de alguma ação ou estado que veio do contexto. No caso, pegar o estado products.

jest.spyOn: faz a simulação de alguma funcionalidade, neste caso simulamos o Local Storage.

mockImplementation: implementa um mock na simulação, neste caso, implementamos o mock de item na simulação de LocalStorage

waitFor: espera por um resultado.

expect: descreve o resultado esperado, aqui nós esperamos que o resultado, ou seja, que o array products tenha um item com o nome igual ao que passamos no mock.

Testando ações

Nosso próximo teste do hook será sobre adicionar items no carrinho. Queremos garantir que a function addToCart está funcionando corretamente.

O início será bem parecido com o teste anterior, da qual vamos renderizar o hook e criar um mock do item. O resultado esperado também será o mesmo, o que vai mudar aqui vai ser justamente o fato de que queremos testar uma açao do hook. Vamos ver como fica:

test('get items from localStorage', async () => {

    // 1. renderizar o hook
    const { result } = renderHook(() => useCart(), {
      wrapper: CartProvider
    });

    // 2. fazer uma query ou mock
    const itemAddedToCart = {
      id: 1,
      createdAt: 'some_value',
      name: 'Product Test',
      price: 90,
      image: 'image_path',
      stock: 9,
    };

    // 3. executar alguma ação
    act(() => {
      result.current.addToCart(itemAddedToCart);
    });

    // 4. descrever o resultado esperado
    await waitFor(() => {
      expect(result.current.products[0].name)
      .toEqual('Product Test');
    });
  });

act: faz com que a renderização seja o mais próximo possível do que acontece no Browser. Neste caso, chamamos no método act a ação que queremos testar e passamos pra ela o mock como parâmetro.

expect: se tudo ocorrer bem, o resultado também será um array products com 1 item adicionado.

O hook ainda tem duas ações para ser testadas: removeToCart e getTotalPrice. Entretanto, fica como desafio, pois da pra fazer baseado naquilo que já vimos aqui.

Testando um Componente que utiliza um Hook

Ok, testamos duas funcionalidades do hook useCart e agora vamos testar um componente que utiliza esse hook, o próprio carrinho de compras. Como sempre, vamos olhar o código do componente:

import React from 'react';

import { ReactComponent as CartIcon } from '../../../assets/cart.svg';
import { useCart } from '../../../hooks/Cart';
import { Container } from './styles';

export default function Cart() {
  const { products } = useCart();

  return (
    <Container to="/cart" data-testid="cart_link_component">
      <CartIcon />
      {products.length > 0 && (
        <div>
          <span>{products.length}</span>
        </div>
      )}
    </Container>
  );
};

Você se lembra qual o primeiro teste que costumamos escrever quando testamos um componente? Isso mesmo, testamos se ele está sendo exibido corretamente na tela.

Entretanto, como esse componente utiliza o hook useCart, não podemos simplesmente testar como já fizemos nos anteriores. Aqui nós precisaremos mockar o hook, já que o componente depende dele.

Vamos utilizar o mesmo método que usamos para simular o LocalStorage, o jest.spyOn. E para mockar também o retorno do hook, vamos passar um objeto pelo método mockReturnValue com o estado products e as ações que o hook disponibiliza.

import React from 'react';
import { BrowserRouter } from 'react-router-dom';
import { render } from '@testing-library/react';
import * as hookCart from '../../../hooks/Cart';

describe('Cart component tests', () => {
  test('renders without crashing', () => {
    jest.spyOn(hookCart, 'useCart').mockReturnValue({
      products: [],
      addToCart: jest.fn(),
      removeToCart: jest.fn(),
      getTotalPrice: 0,
    });

    const { getByTestId } = render(<Cart />, {
      wrapper: BrowserRouter
    });

   expect(getByTestId('cart_link_component')).toBeInTheDocument();
  });
}

import *: vamos importar tudo que vem do hook para simular

jest.spyOn: passando o que foi importado, vamos simular o hook useCart e mockar no mockReturnValue seus valores.

expect: utilizamos o mesmo método anterior de getByTestId e esperamos que o componente esteja na tela.

👉 Veja como testar consumo de API na parte 4

Referências:

Esse conteúdo foi baseado no vídeo “Treinamento: Como implementar testes unitários em React utilizando Jest” do canal da Zappts, feito pelo Cláudio Castro.

Confira o repositório com o projeto: https://github.com/ccastrojr/react_unit_test

[pt-BR] Como Testar Componentes de uma Aplicação em React - #2

Adriana Ferreira Lima Shikasho — Mon, 21 Feb 2022 16:39:10 +0000

O que será abordado:

Primeiros passos
Enxergando Padrões
Escrevendo o primeiro teste de Componente
Testanto Componentes que possuem dependências
Testando um evento de usuário no Componente

Primeiros passos

Vamos imaginar uma aplicação bem simples que simula um ecommerce. Nela teremos duas páginas:

Home: que é a loja que lista todos os produtos. Cada item pode ser adicionado no carrinho ao clique de um botão.

Cart: que é o próprio carrinho da qual podemos ver os itens que foram adicionados para compra e excluí-los caso desejado.

Você encontra o repositório com o projeto aqui

Ao longo da aplicação temos alguns botões, e um deles é o que usamos para adicionar algum item no carrinho. Por isso foi criado um componente único de botão. Vamos ver esse código:

// Button.tsx
import React from 'react';
import { Container } from './styles';

type ButtonProps = React.ButtonHTMLAttributes<HTMLButtonElement> & {
  size: 'default' | 'large';
};

export default Button({ children, ...rest }: ButtonProps) {
  return (
    <Container {...rest} data-testid="pure_button">
      {children}
    </Container>
  );
};

Para incluir um teste para esse componente, vamos criar na mesma pasta um arquivo Button.spec.tsx

Enxergando Padrões

De maneira didática e para nos ajudar a lembrar como deve ser a estrutura de escrita cada teste, podemos pensar em seguir o seguinte padrão:

Renderizar o componente passando suas props
Fazer uma query ou um mock
Executar alguma ação
Descrever o resultado esperado

Uma outra dica que podemos manter em mente é sempre pensar que basicamente tudo em testes é uma simulação. Seria como se fosse uma réplica das funcionalidades, só que todos os dados e ações são "mockados" ou simplesmente falsos.

O objetivo é montar o teste de forma que replique de maneira simulada determinada funcionalidade, mas utilizando as ferramentas que a lib de testes provê. Mas vamos aos poucos que daqui a pouco começa a ficar mais claro.

Escrevendo o primeiro teste de Componente

O título desta suite será “Button component tests” (Testes do componente Button), e o primeiro teste, verificaremos se este componente está sendo exibido corretamente na tela. Esse tipo de teste é o mais básico, e pode ser o primeiro teste para qualquer componente.

// Button.spec.tsx
import React from 'react';
import { render } from '@testing-library/react';
import Button from '.';

describe('Button component tests', () => {
  test('renders without crashing', () => {

    render(<Button size="default" />);

    const button = screen.getByTestId('pure_button')

    expect(button).toBeInTheDocument();
  });
});

Ao enxergar o padrão que explicamos anteriormente, percebemos que neste caso em específico não precisaremos executar nenhuma ação (item 3), mas veremos um exemplo com ação mais pra frente.

  [...]    

  // 1. renderizar o componente passando suas props
  render(<Button size="default" />);

  // 2. fazer a query do componente
  const button = screen.getByTestId('pure_button')

  // 4. descrever o resultado esperado
  expect(button).toBeInTheDocument();

  [...]

describe: descreve um conjunto de testes que estão associados. O describe por si só não executa teste, ele só agrupa os testes de determinado componente. Ele recebe 2 parâmetros: um texto que descreve a suite de testes, e uma função callback. Nessa função, vamos escrever cada teste.

test ou it: implementa o teste. Também recebe 2 parâmetros: um texto bem descritivo do teste, e uma função callback com a execução do teste de fato.

render: usado para identificar qual componente da aplicação que queremos renderizar para testar. Ele precisa receber as props obrigatórias desse compontent. O render retorna vários métodos para fazermos a query desse component. Uma delas é a getByTestId.

getByTestId: para usar essa função é necessario ter o atributo data-testid no componente que queremos testar. Ele é um atributo único que vai nos ajudar a fazer a query do componente.

expect: o que a gente espera que aconteça. Neste caso, a gente espera que o botão esteja no documento, ou seja, que seja renderizado corretamente, então utilizamos o método toBeInTheDocument().

Testanto componentes que possuem dependências

Beleza, já temos nosso primeiro teste, o mais simples deles, agora vamos começar a nos aprofundar um pouco mais. Lembrando na nossa aplicação sendo um ecommerce, nós temos um Link (chamado MenuOption) no menu superior da home que vai nos redirecionar para a página de carrinho.

import React from 'react';
import { LinkProps } from 'react-router-dom';

import { Container } from './styles';

interface Props extends LinkProps {
  label: string;
}

export default function MenuOption({ label, ...rest }:LinkProps ){
  return <Container {...rest}>{label}</Container>;
};

MenuOption;

O primeiro teste, será o mesmo que escrevemos para o botão, mas veremos uma outra forma de fazer a query do nosso componente MenuOption.

describe('MenuOption component tests', () => {
  test('renders without crashing', () => {

    // 1. renderizar o componente passando suas props
    render(<MenuOption label="Link Teste" to="/" />);

    // 2. fazer a query do componente
    const link = screen.getByText('Link Teste')

    // 4. descrever o resultado esperado
    expect(link).toBeInTheDocument();
  });
}

Como podemos ver, fizemos a query utilizando o getByText, em que podemos pegar algum texto que está aparecendo na tela.

Neste caso, o MenuOption exibe um texto que recebe no parâmetro label, entretanto, aqui no teste podemos “mockar” qualquer texto, pois o importante é a query funcionar, e não precisa ser exatamente como na aplicação.

Então vamos passar como parâmetro o label='Link Teste' e vamos usar essa mesma string na query getByText('Link Teste') para selecioná-lo.

Não podemos esquecer de passar no render, todos os parâmetros obrigatórios para aquele componente. Por exemplo, o MenuOption sendo um Link que veio do react-router-dom, ele obrigatoriamente precisa que seja passado um to='/', se não dá erro.

Feito isso, escrevemos o resultado esperado, que é que o componete esteja no documento, conforme já vimos.

Ok, agora vamos rodar nosso teste. Executamos yarn test, e... percebemos que não passou! Ué, o que fizemos de errado?
Vamos verificar qual a mensagem de erro que aparece no console:

Invariant failed: You should not use <Link> outside a <Router>

Mas o que isso significa?

Um componente Link para que ele possa ser renderizado, eu preciso ter por volta dele um Router que é o responsável pelo redirecionamento, sem ele, o link não funciona.

Para resolver isso, vamos envolvê-lo passando um segundo parâmetro no método render, que é um objeto com um wrapper. E dentro do wrapper passamos o BrowserRouter, que é o resposável por criar as rotas e fazer o Link funcionar.

O teste correto vai ficar assim agora:

[...]

// no render passaremos o objeto com wrapper: BrowserRouter
render(<MenuOption label="Link Teste" to="/" />, {
  wrapper: BrowserRouter,
});

[...]

Agora sim! Ao rodar os testes, ele vai passar, pois não teremos nenhum problema de dependência para a renderização do componente.

Então ótimo, agora já aprendemos que toda vez que aparecer essa mensagem de erro de que algum componente não pode ser renderizado fora de outro componente, já sabemos que precisamos “envolvê-lo” com esse componente da qual ele tem dependência.

Testando um evento de usuário no Componente

Certo, como prometemos, vamos ver um exemplo que agora contém os 4 pontos que definimos no nosso padrão de escrita lá trás, que é alguma ação.

Nesse mesmo componente MenuOption, lembrando que ele é um Link e todo link serve para navegação, e normalmente isso é feita através de um clique do usuário no link.

Por isso, nosso próximo teste será verificar se o redirecionamento para a próxima página está funcionando ao clique do usuário no link. Vamos escreve-lo, acrescentando o método userEvent.click().

o método userEvent, descreve exatamente isso, uma ação ou evento feita pelo usuário e pode ser obtida pela importação do '@testing-library/user-event’. Vai ficar assim:

test('click to redirect', () => {
    // 1. renderizar o componente passando suas props
    render(<MenuOption label="Button Test" to="/url" />, {
      wrapper: BrowserRouter,
    });

    // 2. fazer a query do componente
    const link = screen.getByText('Link Teste')

    // 3. executar alguma ação
    userEvent.click(link);

    // 4. descrever o resultado esperado
    expect(global.window.location.pathname).toEqual('/url');
});

Depois do clique o usuário teremos um resultado esperado propício a um link: queremos que aconteça um redirect para uma outra página. E qual será essa página? Será a string que passamos nas prop to que definimos no render do MenuOption, neste caso, to='/url'.

Então lá no expect, vamos usar um método do próprio javascript que pega o pathname da url, o método global.window.location.pathname, e esperamos que ele seja igual a string que deifinimos na prop, utilizando o método toEqual('/url').

👉 Veja como testar hooks na parte 3

Referências:

Esse conteúdo foi baseado no vídeo “Treinamento: Como implementar testes unitários em React utilizando Jest” do canal da Zappts, feito pelo Cláudio Castro.

Confira o repositório com o projeto: https://github.com/ccastrojr/react_unit_test

[pt-BR] Fundamentos de Testes Unitários no Front-end - #1

Adriana Ferreira Lima Shikasho — Mon, 21 Feb 2022 16:38:55 +0000

Os testes unitários são os testes mais básicos da cadeia de testes no desenvolvimento de software.

Diferentemente dos outros tipos de teste (integração e e2e), os testes unitários, também chamados de teste de unidade, garantem que uma pequena unidade esteja funcionando mesmo desconectada de todo o restante da aplicação.

Eles nos ajudam a garantir uma entrega com maior qualidade, visto que podem ser rodados sempre que uma nova implementação for feita no código e garantir que nada esteja quebrado antes do deploy.

Veremos neste conteúdo, os fundamentos básicos da implementação de testes unitários em React, utilizando a a react-testing-library. Você pode consultar no final da página a referência utilizada para produção deste conteúdo.

Este conteúdo esta dividido em 4 partes, sendo esta a parte mais teórica e as demais são práticas, em que você aprenderá:

Como testar componentes
Como testar hooks
Como testar chamadas a APIs

Nesta série nos preocuparemos mais no "como testar", qual ferramenta ou qual método utilizar. Mas se você quiser expandir ainda mais seu conhecimento sobre testes, recomendo que você leia esta série sobre "o que testar" no front-end. Confira aqui.

O que será abordado:

Testes unitários no front-end
A responsabilidade de um componente
Prevenindo falsos-positivos

Testes unitários no front-end

Antes de ir para a parte prática, vamos entender como os testes unitários se aplicam a interface, a começar por uma simples analogia:

A estrutura de um front-end de uma aplicação web poderia ser comparada a um quebra-cabeça. Se uma das peças se quebrar de forma que não possa mais ser encaixada a outra peça, a imagem ficará comprometida e a peça quebrada precisará ser consertada.

Se tratando de front-end, as peças são os componentes e o quebra-cabeça é a aplicação. Embora seja comum componentes quebrarem durante o desenvolvimento, não queremos de forma alguma que nossos componentes estejam quebrados em produção. Seria um desastre!

E para evitar isso, implementamos testes unitários em cada componente, de forma a garantir que tudo está funcionando bem.

Entretanto, para escrever bons testes no front-end, o código também deve ser bem escrito, a lógica dos componentes também deve ser bem pensada.

A qualidade dos testes andam de mãos dadas com a qualidade dos componentes!

A responsabilidade de um componente

Se lembrarmos do princípio da responsabilidade única, em que uma classe ou componente, deve ter uma única e exclusiva responsabilidade, podemos melhorar a qualidade do componente.

Entretanto, caso um componente ainda esteja com mais reponsabilidades do que deveria, os testes vão nos ajudar a identificar.

Se ao escrever testes percebermos que será necessário testar duas funcionalidades em um mesmo componentes, já é um alerta de que possivelmente teremos que dividí-lo em dois componentes distintos.

Um exemplo prático seria algo como, um componente button que também tem a função de navegação. Pensando em boas práticas de desenvolvimento, isso não seria algo certo, pois botão é botão e link é link.

Prevenindo falsos-positivos

Os testes uniários também nos ajudam a prevenir falsos-positivos. Ao dar manutençao e testar uma única rotina, podemos pensar que tudo está funcionando bem, quando na realidade podem ainda haver bugs em nosso código.

Vamos supor que alteramos alguma coisa no componente B, e precisamos saber se gerou alguma alteracao no componente A. É muito comum testarmos manualmente apenas o componente A e não testar o componente B ou até mesmo outros módulos que o utilizam.

Acabamos assumindo que tudo está funcionando, quando na realidade pode ter algo quebrado. Assim, os testes unitários rodando antes de cada deploy, testam tanto o componente A que sofreu manutenção, quanto o componente B que usa o componente A e garante se tudo ainda está funcionando conforme o esperado.

👉 Vamos ver agora na prática? Leia a parte 2

Referências:

Esse conteúdo foi baseado no vídeo “Treinamento: Como implementar testes unitários em React utilizando Jest” do canal da Zappts, feito pelo Cláudio Castro.

Confira o repositório com o projeto: https://github.com/ccastrojr/react_unit_test

[pt-BR] Testes de Caso de Uso no React - #3

Adriana Ferreira Lima Shikasho — Mon, 07 Feb 2022 14:39:38 +0000

Por muitas vezes ao pensar em testes do React, já pensamos direto em testes de detalhes de implementação. E já vimos por aqui o quando esse caminho pode acabar mascarando erros, ou atrapalhando a produtividade por serem muito frágeis.

Portanto, para aplicar os Testes de Caso de Uso no React, podemos sempre pensar em qual efeito observável que aquele código que quero testar tem para os nossos usuários como por exemplo, partes relacionadas a Métodos de ciclo de vida, Eventos dos elementos ou Estado interno de componentes.

Vamos ver aqui algumas técnicas práticas a pensar que vão para facilitar a implementação de testes em uma aplicação em React.

O que será abordado:

Como aplicar Testes de Caso de Uso no React?
React Testing Library
Conclusão

Como aplicar Testes de Caso de Uso no React?

Provavelmente isso não é uma regra, mas podemos divir algumas partes do código do React pensando a que tipo de usuário ela se refere. Por exemplo:

O usuário-final vê e interage com aquilo que renderizamos, ou seja, tudo o que está dentro do render ou return.

O usuário-desenvolvedor vê e interage com os adereços que passamos para os componentes, como props, estados, contextos.

Também temos elementos que precisamos testar e que são preocupantes para ambos, como por exemplo mudança na DOM, uma chamada HTTP, chamadas callback, ou outros tipo de efeitos colaterais que são observáveis como:

Interações do usuário: O usuário final é capaz de interagir com os elementos que o componente renderiza?

Mudanças de props: O que acontece quando o usuário-desenvolvedor re-renderiza o componente com novas props?

Mudanças de contexto: O que acontece quando o usuário desenvolvedor altera o contexto, resultando na rerenderização do seu componente?

Alterações de subscription: O que acontece quando um emissor de evento relacionado a algum componente muda? (Como firebase, uma store do redux, uma rota, uma media query ou assinaturas baseadas em navegador, como status online)

React Testing Library

Essa é uma ferramenta criada exclusivamente com o objetivo de escrever testes para manutenção de componentes React de forma que evite testar detalhes de implementação e manter a aplicação sustentável a longo prazo.

Vamos ver um exemplo de teste utilizando o React Testing Library, utilizando o mesmo exemplo do accordion que usamos na parte 1, só que vamos reescrevê-lo em functional component com hooks:

// accordion.js
export default function Accordion({ items })  {
    const [openIndexes, setOpenIndex] = useState([0])

    return (
      <div>
        {items.map((item, index) => (
          <>
            <button onClick={() => setOpenIndex([index])}>
              {item.title}
            </button>

            {openIndexes.includes(index) ? (
              <AccordionContents>
                {item.contents}
              </AccordionContents>
            ) : null}
          </>
        ))}
      </div>
    )
}

E agora escrevemos o teste, pensando no comportamento observável do componente:

"Pode abrir items do accordion e ver seus conteúdos"

test('Pode abrir items do accordion e ver seus conteúdos', () => {
  const hats = {
     title: 'Chapéu Favorito',
     contents: 'Fedoras são legais'
  }
  const footware = {
    title: 'Calçado Favorito',
    contents: 'Chinelos são os melhores',
  }

  render(<Accordion items={[ hats, footware  ]} />)

  expect(screen.getByText(hats.contents)).toBeInTheDocument()
  expect(screen.queryByText(footware.contents))
  .not.toBeInTheDocument()

  userEvent.click(screen.getByText(footware.title))

  expect(screen.getByText(footware.contents)).toBeInTheDocument() 
  expect(screen.queryByText(hats.contents))
  .not.toBeInTheDocument()
})

Incrível! Agora temos um único teste que verifica todo o comportamento do componente. E esse teste vai passar mesmo se o nome do estados for openIndex, openIndexes, ou tacosAreTasty, não importa!

Conclusão

Acredito que é seguro dizer que normalmente os desenvolvedores não tem tanta vontade assim de escrever testes, muito menos seguindo metolodogias como TDD, BDD, FDD, DDD ou outras.

Entretanto, todos sabem da sua real importância e acredito que essa cultura de só codar sem implementar testes vai acabar ficando pra trás, pois sabemos o quanto contribui para a confiabilidade do código e isso é o que todo mundo quer!

Já vi gente dizer que escrever testes pra front-end é um caos, pois não existia padrão ou alguma ferramenta mais simples de configurar.

Entretanto, como vimos nesse material, já não está mais tão ruim assim implementar os testes no front-end e espero que surjam cada vez mais autores como o Kent C. Dodds para trazer essas abordagens práticas de testes no front-end.

Além disso, as ferramentas tem avançado também como vimos com o React Test Library, e diversas outras como o Enzime, e o Jest sendo este o mais popular, talvez por ser nativo do create-react-app.

Por fim, agora que aprendemos "o que" testar, podemos facilmente integrar esse conhecimento com o estudo dessas ferramentas e melhorar ainda mais a qualidade nos nossos testes.

Caso queira conhecer agora o "como" testar, deixo algumas recomendações abaixo que podem introduzir o assunto:

"Guia rápido de testes no front-end" - Thayse Onofrio
https://dev.to/thayseonofrio/guia-rapido-de-testes-no-front-end-2lpc
"Testes automatizados em React" - Thiago Ferreira
https://medium.com/luizalabs/testes-automatizados-em-react-e431db826d65
"Jest: Escrever testes nunca foi tão divertido" - Eduardo Rabelo
https://oieduardorabelo.medium.com/jest-escrever-testes-nunca-foi-t%C3%A3o-divertido-5f0e1950ba10

Referências:
"How to know what to test" - Kent C. Dodds
https://kentcdodds.com/blog/how-to-know-what-to-test
"Avoid the Test User" - Kent C. Dodds
https://kentcdodds.com/blog/avoid-the-test-user
"Testing Implementation Details" - Kent C. Dodds
https://kentcdodds.com/blog/testing-implementation-details

[pt-BR] Conheça a melhor forma de escrever testes no seu front-end - #2

Adriana Ferreira Lima Shikasho — Mon, 07 Feb 2022 14:38:15 +0000

Como vimos na Parte 1, testar detalhes de implementação no front-end pode ser uma armadilha que pode acabar mascarando erros gerando falso-positivos ou falso-negativos ou até mesmo atrapalhando a produtividade por serem muito frágeis.

Vamos então abordar de maneira prática um caminho para se pensar em testes no front-end de forma que eles se tornem mais confiáveis e com mais qualidade.

O que será abordado:

Testando Casos de Uso
Cobertura de Código
Cobertura de Casos de Uso
Quando a Cobertura de Código oculta os Casos de Uso

Testando Casos de Uso

"Quanto mais seus testes se assemelham à forma como seu software é usado, mais confiança eles podem lhe dar." - Kent C. Dodds

Essa é a natureza dos testes de casos de uso, pensar em escrever testes que atendam a forma que nossos dois usuários** (usuário-final e usuário-desenvolvedor) usam e interagem com nossa aplicação.

**ver Detalhes de implementação da parte 1

Escrevemos testes para ter certeza de que nosso aplicativo funcionará quando o usuário os usar e principalmente melhorar a confiança da aplicação.

"Pense menos no código que você está testando e mais nos casos de uso que o código suporta." - Kent C. Dodds

Cobertura de Código

Cobertura de código é a métrica que nos mostra quais linhas do nosso código estão rodando durante o teste. Vamos utilizar esse código como exemplo:

function verificaArray(array) {
  if (Array.isArray(array)) return array
  else if (!array) return []
  else return [array]
}

Sem incluir teste para essa função, o relatório vai indicar que 0% de Cobertura de código nos dando a ideia de quanta parte do código ainda falta cobrir.

O relatório de Cobertura de código não diz exatamente qual a importância da função verificaArray ou nem mesmo diz os casos de uso que ela atende.

Mas quando consideramos a aplicação inteira, mesmo o relatório de Cobertura de código não nos dando uma a visão completa, ele nos ajuda a identificar quais testes poderiam ser adicionados para atender os casos de uso da aplicação.

Cobertura de Casos de Uso

A Cobertura de Casos de Uso nos diz quantos casos de uso nosso teste atende. Voltando ao código de exemplo, podemos identificar o primeiro caso de uso da função verificaArray:

"Retorna um array se o argumento for um array".

Obs: Há uma convenção de escrever os títulos dos testes em inglês, entretanto neste estudo, vou escrevê-los em português-BR por uma questão didática, beleza?

test('Retorna um array se o argumento for um array', () => {
  expect(verificaArray(['Elefante', 'Girafa']))
  .toEqual(['Elefante', 'Girafa'])
})

E com esse teste escrito, nosso relatório de Cobertura de Código vai parecer com algo do tipo:

function verificaArray(array) {          // coberto
  if (Array.isArray(array)) return array // coberto
  else if (!array) return []
  else return [array]
}

Assim, se olharmos para as linhas que faltam, vamos concluir que são mais dois casos de Uso que faltam ser cobertos:

"Retorna um array vazio se o argumento tiver um valor falso"
"Retorna um array se o argumento não for um array e não for falso"

Vamos adicionar os testes para esses casos de uso, e ver como isso afeta a Cobertura de Código

test(
'Retorna um array vazio se o argumento tiver um valor falso', () => {
   expect(verificaArray()).toEqual([])
})

test(
`Retorna um array se o argumento não for um array e não for falso`,
() => {
  expect(verificaArray('Leopardo')).toEqual(['Leopardo'])
})

Cobertura:

function verificaArray(array) {          // coberto
  if (Array.isArray(array)) return array // coberto
  else if (!array) return []             // coberto
  else return [array]                    // coberto
}

Ótimo! Agora temos 100% de cobertura de código, mas também 100% de cobertura de casos de uso e podemos confiar que, enquanto não mudarmos os casos de uso dessa função, nossos testes vão continuar passando.

Quando a cobertura de código oculta os casos de uso

As vezes, o relatório de Cobertura de código pode indicar 100% de cobertura, mas não 100% de cobertura de casos de uso.

Esse é o motivo que é bom ter a prática de pensar em todos os casos de uso possíveis antes mesmo de começar a escrever os testes.

Por exemplo, vamos imaginar que a function verificaArray foi implementada desse jeito:

function verificaArray(array) {         
  if (Array.isArray(array)) return array
  else return [array].filter(Boolean)                   
}

Com isso, nós temos 100% de cobertura com apenas os 2 casos de uso:

Retorna um array se o argumento for um array
Retorna um array se o argumento não for um array

Entretanto, se olharmos para o relatório de Cobertura de caso de uso, podemos perceber que está faltando um caso de uso:

Retorna um array vazio se o argumento tiver um valor falso

E isso é um mau sinal, pois mesmo se o usuário user a função verificaArray sem passar nenhum argumento, os testes vão continuar passando, mas o código vai quebrar.

E essa é justamente uma das razões que implementamos testes, garantir que o código continue atendendo aos casos de uso que desejamos incluir.

Por exemplo, se um outro dev remover o .filter(Boolean), os testes ainda continuam passando, mas qualquer código que dependia do resultado da function como sendo "falso", vai quebrar.

👉 Continue lendo na parte 3

[pt-BR] Quer testar sua interface? Entenda o que não fazer - #1

Adriana Ferreira Lima Shikasho — Mon, 07 Feb 2022 14:37:24 +0000

Os testes compõe uma parte fundamental no processo de desenvolvimento de software. Apesar disso, muita gente acha os testes desagradáveis, principalmente os testes de interface.

Existem várias razões para isso, mas das mais comuns é que fazer e manter os testes gastam muito tempo. "Toda vez que faço uma alteração no código, os testes quebram!"

E no fim, de certa forma estão até corretas, porque testes quebrando o tempo todo é um grande empecilho para a produtividade. Entretanto, e se eu te disser que existe algumas formas de evitar essas frustrações e começar a implementar testes de interface mais confiáveis?

Quando estudamos testes, sendo pra front ou back, por muitas vezes nos preocupamos em conhecer seus fundamentos ou quais ferramentas utilizar, ou seja, tópicos que tem mais a ver com "como" implementar os testes do que "o que" realmente testar.

De acordo com Kent C. Dodds, definir muito bem "o que" testar é o ponto-chave para agregar mais valor e confiabilidade aos testes.

O conteúdo desse artigo utiliza como referência alguns textos do Dodds e está dividido em 3 partes: a primeira descreve o que não fazer ao escrever testes para o front-end; na segunda parte, veremos qual a melhor prática para escrever testes confiáveis e por fim, na última parte, veremos um pouco de como pensar os testes seguindo estrutura de código do React.

Você pode conferir as referências ao final de cada parte destes posts.

O que será abordado:

Porque fazer testes?
Detalhes de implementação
Falso-negativo
Falso-positivo

Porque fazer testes?

Em termos gerais, fazemos testes para que tenhamos sempre a confiança de que a aplicação vai funcionar como esperado quando o usuário a utilizar.

E pensando no usuário e como ele utiliza a aplicação, podemos chegar em uma metodologia que vai nos guiar a escrever testes e garantir que tragam cada vez mais confiança:

"Pensar menos sobre linhas de código e mais sobre Casos de Uso que o código atende." - Kent C. Dodds

Quando pensamos apenas sobre linhas de código ao invés de pensar em casos de uso, fica muito fácil nos perdemos e começarmos a nos preocupar em testar "detalhes de implementação", o que logo mais veremos que é uma pratica que pode gerar consequencias ruins ao desenvolvimento.

Por isso, antes mesmo de nos aprofundarmos nos testes de caso de uso que é basicamente "o que" devemos testar, vamos ver o que NÃO devemos testar na aplicação.

Detalhes de implementação

De maneira simples, podemos definir os detalhes de implementação como:

"Coisas que os usuários do seu código normalmente não usarão, verão ou sequer conhecerão." - Kent C. Dodds

E quem são os usuários do nosso código? Bom, quando escrevemos código, precisamos manter em mente que devemos atender apenas a 2 tipos de usuários:

O usuário-final: é aquele que interage com o componente (por exemplo, insere valores em inputs de um form, clica no botão enviar ou reset, recebe mensagem de carregamento e success)

O usuário-desenvolvedor: é o que renderiza o componente (por exemplo, inclui o componente em um UserProvider para atualizar seu estado e fazer dispatch pra o contexto)

Entretanto, quando fazemos testes de detalhes de implementação, acaba surgindo um terceiro usuário, que é o usuário-tester. Esse tipo de usuário não deve ter atendido, pois criando testes pra eles, faremos com que esses testes não se assemelhem à forma que a aplicação é usada pelos usuários que são importantes.

Há duas razões distintas pelas quais é importante evitar testar detalhes de implementação:

Pode quebrar quando você refatora o código do aplicativo, gerando Falso-negativo.
Pode acabar não falhando quando o código quebrar, gerando Falso-positivo.

Vamos para um exemplo em React, utilizando um componente accordion simples:

// accordion.js
class Accordion extends React.Component {
  state = {openIndex: 0}
  setOpenIndex = openIndex => this.setState({openIndex})

  render() {
    const {openIndex} = this.state

    return (
      <div>
        {this.props.items.map((item, index) => (
          <>
            <button onClick={() => this.setOpenIndex(index)}>
              {item.title}
            </button>

            {index === openIndex ? (
              <AccordionContents>
                {item.contents}
              </AccordionContents>
            ) : null}
          </>
        ))}
      </div>
    )
  }
}

export default Accordion

E agora um teste utilizando a ferramenta Enzyme, para testar os detalhes de implementação:

// __tests__/accordion.enzyme.js
test('setOpenIndex sets the open index state properly', () => {
  const wrapper = mount(<Accordion items={[]} />)
  expect(wrapper.state('openIndex')).toBe(0)
  wrapper.instance().setOpenIndex(1)
  expect(wrapper.state('openIndex')).toBe(1)
})

Ok, agora vamos entender como as coisas quebram fácil com esse tipo de teste.

Falso-negativo

Digamos que seja necessário refatorar este accordion a permitir que vários itens sejam abertos de uma só vez. Agora, vamos fazer essa alteração na implementação de modo que não altere seu comportamento:

// accordion.js
class Accordion extends React.Component {
  state = {openIndexes: [0]}
  setOpenIndex = openIndex => this.setState({openIndexes: [openIndex]})

  render() {
    const {openIndexes} = this.state

    return (
      <div>
        {this.props.items.map((item, index) => (
          <>
            <button onClick={() => this.setOpenIndex(index)}>
              {item.title}
            </button>

            {openIndexes.includes(index) ? (
              <AccordionContents>
                {item.contents}
              </AccordionContents>
            ) : null}
          </>
        ))}
      </div>
    )
  }
}

export default Accordion

Legal! Agora a gente abre a aplicação e ve que tudo está funcionando corretamente, conforme desejamos e caso desejemos replica-lo também será muito fácil.

Aí, vamos rodar os testes eles travaram. Vemos que o teste que quebrou foi: setOpenIndex sets the open index state properly. E a mensagem de erro é a seguinte:

expect(received).toBe(expected)

Expected value to be (using ===): 0
Received: undefined

Essa falha no teste está nos alertando sobre um problema real? Não! Pois o componente ainda está funcionando.

Isso é o que se chama de falso negativo. Isso significa que tivemos uma falha no teste, mas foi por causa de um teste quebrado, não porque o código está quebrado.

Bem, a solução então para esse caso é alterar o teste:

test('setOpenIndex sets the open index state properly', () => {
  const wrapper = mount(<Accordion items={[]} />)
  expect(wrapper.state('openIndexes')).toEqual([0])
  wrapper.instance().setOpenIndex(1)
  expect(wrapper.state('openIndexes')).toEqual([1])
})

Chegamos então à primeira conclusão que testar detalhes de implementação podem gerar falso-negativo quando há alguma refatoração no código, o que torna os testes frágeis e frustantes que parecem falhar em simplesmente olhar o código.

Falso-positivo

Ok, agora vamos dizer que seu colega de trabalho está trabalhando no accordion e ele vê este código:

<button onClick={() => this.setOpenIndex(index)}>{item.title}</button>

Imediatamente, pensando prematuramente em otimizar ele pensa: "Ei! Arrow functions inline são ruins para performance! Vou corrigir aqui rapidinho e fazer os testes."

<button onClick={this.setOpenIndex}>{item.title}</button>

Aí ele faz os testes e, tcharam! Passaram! Aí sem mesmo olhar no navegador o componente funcionando, ele manda abre um PR, é aprovado e o accordion quebra em produção!

Mas o que deu errado? O teste verificava se o estado mudava quando o setOpenIndex era chamado e se o conteúdo era exibido corretamente. Sim, está correto, o problema é que não houve teste para verificar se evento onClick do botão estava chamando o setOpenIndex corretamente.

Isso é chamado de falso positivo, o que significa que o teste não falhou mas deveria ter falhado! Então, o que podemos fazer para garantir que não ocorra novamente?

Poderíamos pensar em algumas ações como: adicionar outro teste para verificar se clicar no botão atualiza o estado corretamente ou simplesmente usar uma ferramenta gratuita que nos auxilia a evitar testar detalhes de implementação.

Eu gosto dessa segunda alternativa, aposto que você também! Veremos esses detalhes na parte 3 em que falamos sobre os testes no React!

Mas por enquanto, vamos seguir a linha de raciocínio e aprender sobre os testes que realmente devemos nos preocupar em escrever: "Testes de caso de uso".