DEV Community: Marlon Marques

Além dos Testes unitários: Não é somente escrever

Marlon Marques — Sun, 15 Oct 2023 19:06:24 +0000

Este artigo expande o tópico anterior sobre Como implementar uma Cultura de Testes Unitários na sua Equipe. Mergulhando mais profundamente nos Testes Automatizados para impulsionar o Desenvolvimento Ágil.

Agora que a sua equipe realiza entregas de funcionalidades com testes unitários. Os incidentes caíram em 90%, não existem mais bombeiros para apagar incêndio, os QAs não encontram mais bugs e estão destinados apenas em validar a qualidade do software. Bem, era isso que eu queria poder dizer, mas não é bem assim rs.

Ao alcançar entregas de funcionalidades com testes unitários, pode-se esperar uma significativa redução de incidentes e uma transição suave para uma cultura de desenvolvimento mais segura. No entanto, a realidade muitas vezes não reflete essa expectativa inicial, como será discutido ao longo deste artigo.

Longo prazo vs Curto prazo

Aprender a arte dos testes unitários enquanto se realiza entregas de funcionalidades não é uma tarefa trivial e impacta o tempo de entrega. No entanto, esse esforço inicial é um investimento fundamental na qualidade a longo prazo. Além dos pontos negativos iniciais, como o esforço adicional e o aumento do tempo de entrega, os benefícios começam a surgir à medida que a equipe ganha experiência.

Esforço: Obviamente, escrever testes unitários não é nada fácil. Além de ter que pensar em como validar uma funcionalidade, você tem que saber utilizar artifícios para que isso se torne possível. Alguns desses artifícios são por exemplo: Mock's, Spies etc.
Aumento do tempo de entrega: Alinhado ao esforço, acaba-se levando mais tempo para entregar uma funcionalidade, é claro, além de implementar, ainda é necessário testar (que saco 😵‍💫).

Entregas mais rápidas tornam-se possíveis à medida que os desenvolvedores dominam a prática de escrever testes unitários, o que acaba levando a uma redução de bugs encontrados.

Entregas mais rápidas: O que antes exigia um maior esforço, acabou-se tornando menos burocrático, devido a experiência obtida na arte de escrever testes unitários, levando a entregas mais rápidas.
Redução de bugs: Isso, por sua vez, leva a uma redução significativa nos bugs encontrados durante as revisões das funcionalidades pelos QAs, resultando em menos incidentes após a implantação.

Qualidade do Código

Muitos autores citam que os testes unitários devem ser tão legíveis quanto o código (ou talvez até mais), porém, como você vai escrever um teste legível se você ainda está sofrendo para fazê-lo passar?

A qualidade dos testes unitários é crucial para o sucesso a longo prazo. Embora, inicialmente, os testes possam parecer longos e complexos, a prática constante leva a uma compreensão mais clara e a testes mais eficientes. Com isso, surgem conceitos como Injeção de Dependência e Inversão de Dependência. Abordagens essas, não apenas aprimoram a legibilidade dos testes, mas também contribuem para um código mais limpo e menos acoplado.

Os fantasmas voltam a assombrar a equipe

Vocês estão indo bem, os testes unitários estão evoluindo, mais entregas sendo feitas com testes unitários. Vocês começam a definir uma régua para a Cobertura do Código. Agora todos tem o costume de rodar os testes unitários para verificar se a cobertura de código está sendo respeitada. Porém, o fantasma volta a te assombrar!

Mesmo com o progresso, os testes unitários não são imunes a desafios. A questão dos Testes Não-Determinísticos pode surgir, causando inconsistências nos resultados dos testes. (Para que serve um teste que não podemos confiar? De nada!)

Martin Fowler sugere uma solução prática: mover esses testes para quarentena. Isso envolve segregá-los para que não impactem a confiança nos testes unitários enquanto são analisados e corrigidos.

Integração Continua

Após superar desafios, a equipe amadurece para adotar os Testes Unitários como métrica de confiança e qualidade do software. A Integração Contínua, ativada sempre que um PR é feito para a branch de desenvolvimento, desempenha um papel crucial nesse processo. Alguns pontos importantes a serem seguidos incluem:

Com o consentimento da equipe, não reduzir a régua da cobertura dos testes unitários.
O PR não é mesclado se a cobertura ficar abaixo do estipulado.
Se algum teste quebrar durante a varredura dos testes unitários, o PR não é mesclado até que o teste seja corrigido.

Por fim, algo de suma importância é não dar um passo para atrás. No decorrer desse processo, você pode se deparar com cenários como: Remover a régua da cobertura dos testes unitários, ou abrir uma exceção para um PR de incidente etc. Esses são males que você deve resistir se quiser alcançar um software de qualidade.

Conclusão

Escrever testes unitários vai além da codificação; é uma questão cultural e organizacional. Embora inicialmente desafiador, o investimento em práticas eficazes de testes unitários resulta em entregas mais rápidas, qualidade de código aprimorada e uma experiência mais estável para os usuários. Como defensores da Qualidade de Software, é crucial manter a integridade dos testes unitários, apoiando a equipe para alcançar a cobertura desejada. Em última análise, aproveitar todo o potencial dos testes unitários exige uma abordagem holística e contínua.

Pense bem antes de usar o try catch

Marlon Marques — Sat, 24 Jun 2023 20:04:26 +0000

Acredito que todo leitor já usou ou já ouviu falar do try catch. As declarações try catch marcam um bloco de declarações para testar (try), e especifica uma resposta, caso uma exceção seja lançada.

Com isso, eu lhe pergunto: Existe algum mal em usar o try catch? E a resposta é, não. Eu poderia muito bem terminar por aqui. Porém, irei formular mais essa resposta.

O que me levou a escrever esse artigo?

Recentemente estava eu conversando com um amigo sobre a utilização de um try catch para a resolução de um problema no código.

A utilização de um try catch resolve em grande parte a maioria dos problemas quando falamos de tratamento. Porém, vale a pena sempre utilizar o try catch?

Bloco try/catch serve para tratamento de exceções, tratamento de códigos que podem não ser totalmente atendidos e gerarem alguma exceção/erro. Rafael Withoeft

Em casos onde se é totalmente entendível os cenários, por que não utilizar uma simples condicional? Ou seja, prefira o uso de condicionais ao try catch, e caso não seja possível, somente então utilize o try catch.

Vamos entender através do código

const isDev = (about: string) => {
    return about.includes('developer')
}

const response = isDev('My name is Marlon, I am Brazilian, I live in Rio Grande do Sul and I work as a developer.')

console.log(response)

Vamos nos atentar a função isDev.

Vamos imaginar que recebemos o parâmetro de algum serviço. Com isso, existem grandes possibilidades de o parâmetro retornar undefined ou null. O que aconteceria com a nossa aplicação caso chamássemos isDev recebendo via parâmetro um undefined? Isso mesmo, a aplicação quebraria!

Uma forma de resolver esse problema, seria colocando um try catch em volta da validação. Obviamente esse é um cenário muito simples para usar um try catch, mas para o objetivo do artigo, já serve.

const isDev = (about: string) => {
    try {
        return about.includes('developer')
    } catch(error) {
        return false
    }

}

Agora caso ocorra algum problema, sempre retornaremos um false.

Porém, outra forma de resolver esse problema é utilizando uma condicional.

const isDev = (about: string) => {
    if(about) {
        return about.includes('developer')
    }
    return false 
}

A questão é, existem cenários que dificilmente você imagina que o parâmetro pode ser undefined ou null, levando a não tratar esses cenários. E quando trata, usa um try catch sem necessidade.

Como resolver o problema do try catch?

Para mim a melhor solução é utilizar testes unitários. Assim, você consegue validar todos os tipos de cenários possíveis, mas ainda assim, você pode cair na armadilha de esquecer algum cenário e acabar gerando um problema em produção.

Para isso, costumo utilizar o TDD (Test-Driven Development), assim você consegue pensar em todos os cenários de erros enquanto está desenvolvendo. Devido o fato de o TDD se basear no fluxo: Red, Green, Refactor, que respectivamente, significa: Faça o teste quebrar, faça o teste passar e em seguida, refatore. O que faz o TDD ser tão útil para a evitar problemas é a etapa Red. Onde normalmente você acaba passando/pensando nos cenários de erros e assim, ir cobrindo os cenários com testes unitários.

Portanto, utilizo o try catch somente quando realmente necessário, quando estou consumindo algum serviço externo que não é claro os cenários que podem ocasionar erros. Se esse não for o caso, utilizo condicionais em conjunto com testes unitários, para cobrir todos os possíveis cenários de erros.

Vale a pena testar o estilo no Front-end?

Marlon Marques — Thu, 20 Apr 2023 15:40:25 +0000

Não é novidade para ninguém que quanto mais testes automatizados sua aplicação possui, melhor é a confiança e segurança ao realizar alterações e refatorações no código.

Porém, não basta só escrever testes automatizados, mas sim, escrever de forma correta. Para isso, é muito importante entender os conceitos de testes automatizados. Por sorte, temos uma ilustração que mostra isso perfeitamente.

Onde eu quero chegar com isso? A grande parte dos testes automatizados devem ser compostos de testes unitários devido ao seu feedback rápido (conforme podemos visualizar na pirâmide de testes). Mas não somente testes unitários, podemos também mencionar os testes de UI e testes de estilização!

A grande questão é, o quanto devo validar a minha estilização? Devo cobrir 100% da estilização?

Como sempre, a resposta é...depende!

Conheço alguns dev's que costumam testar a aplicação de ponta a ponta, desde a estilização até os testes e2e (end-to-end). Já eu, não costumo testar a estilização das minhas aplicações, há não ser que faça parte de um comportamento funcional.

Como exemplo irei falar sobre um cenário que passei recentemente:

Nós que desenvolvemos aplicações de multiplataformas, devemos sempre nos preocupar se o design está conforme esperado. Principalmente quando falamos de Android e iOS.

Querendo ou não, sempre existe uma diferença de espaçamento ou design etc., entre as plataformas. E é aí que podemos utilizar os testes automatizados para validar esse comportamento de acordo com a plataforma especificada, que foi o meu caso.

Então, em vez de eu ficar validando visualmente conforme a plataforma especificada... Como um adotante do TDD (Test-Drive Development), comecei a escrever os testes de UI para estes comportamentos que variam conforme plataforma.

Assim, me assegurei que o que estava funcionando na plataforma Y, continuaria funcionando. E ao implementar para a plataforma X, não impactaria o que foi feito para a plataforma Y.

Portanto, entendo que os testes automatizados e em específico: testes unitários, testes de UI etc., devem validar o comportamento da funcionalidade. Se o estilo da aplicação muda conforme algum comportamento ou regra de negócio, seria interessante ter um teste automatizado para validar o mesmo.

Até a próxima.

TDD: D de development ou design?

Marlon Marques — Sun, 08 Jan 2023 20:49:07 +0000

Navegando pelo Linkedin me deparei com uma publicação do Vaughn Vernon (autor do Implementando Domain Driven Design) qual me chamou muita atenção, sendo a qual me inspirou a escrever esse artigo.

Resumidamente, em sua publicação Vaughn Vernon fala sobre o segundo "D" do TDD (Test Driven Development) onde menciona que muitos desenvolvedores utilizam o segundo D para Design, e isso está errado. Porém, a publicação gerou diversos comentários interessantes que agregam muito para o conteúdo proposto.

Para quem utiliza o TDD de fato, sabe muito bem os benefícios que podem trazer para sua aplicação, o fato de escrever os testes antes do código de produção. Não irei mencionar todos, mas alguns dos principais são:

Uma aplicação mais segura/confiável, devido o fato de você estar escrevendo suas funcionalidades baseadas nos cenários bons e ruins.
Maior cobertura de testes unitários, quando você escreve o teste antes da funcionalidade, consequentemente você está cobrindo todos os cenários. Assim levando a uma maior cobertura. (É obvio que cobertura não é sinal de um código de qualidade/seguro, mas pode ser um bom parâmetro.)
E o que tem maior relação com o artigo: Uma aplicação mais desacoplada. Quando você está escrevendo os testes antes da funcionalidade, você se preocupa em facilitar a testabilidade do seu código, assim, afetando diretamente o seu código de produção.

No entanto, muitos desenvolvedores vão além disso, começam a utilizar o TDD para manipular o Design da aplicação. E é ai chegamos aos comentários, comentários esses onde levantaram pontos bastantes interessantes na abordagem do TDD e como ele reflete na sua aplicação.

Como já mencionei, é inegável que o TDD vai impactar positivamente a sua aplicação, a nível de qualidade de código, porém, não deve passar disso! A partir do momento que você deixa seus testes unitários direcionarem o Design da sua aplicação, você pode estar comprometendo a sua aplicação apenas pelo fato de estar facilitando a sua escrita de testes.

Para isso, existem práticas que podem ser abordadas antes mesmo do desenvolvimento, onde você começa a definir o Design da sua aplicação. Para isso, você pode utilizar o DDD (Domain Driven Design).

Aqui estão algumas abordagens que você pode colocar em prática utilizando o DDD:

Utilize a Linguagem Onipresente/Ubíqua para que você possa refletir os principais conceitos abordados com os especialistas do domínio no design da sua aplicação.
Delimite os Contextos da sua aplicação, fazendo isso, os desenvolvedores terão um melhor entendimento sobre a aplicação, agregando em um conhecimento compartilhado.
Com os Contextos Delimitados, utilize o Mapa de Contextos, para representar a comunicação entre os Contextos, dando maior clareza do todo da aplicação.

Qual seria o mundo ideal? Utilize o DDD para refletir a Linguagem Onipresente no seu Design e utilize o TDD para ter uma aplicação confiável e de qualidade.

Portanto, não utilize o TDD para refletir o seu Design, o TDD foi feito para se ter uma aplicação mais segura e confiável, consequentemente afetando a qualidade do seu código. Utilize o DDD para ter um design com contextos delimitados baseando-se na linguagem onipresente/ubíqua.

MVVM com Factory no React Native

Marlon Marques — Mon, 14 Nov 2022 12:43:05 +0000

Recentemente encontrei um vídeo muito bom falando sobre Arquitetura MVVM no React Native. Realmente é um assunto que não é muito abordado na comunidade React/React-Native. O que acaba tornando o conteúdo abordado de grande importância.

Portanto, a proposta deste conteúdo é trazer um complemento sobre a abordagem do Padrão de Arquitetura MVVM utilizando o Padrão de Projeto Factory.

Diferente do MVP (Model-View-Presenter), o MVVM (Model-View-ViewModel) traz uma proposta onde deixamos o tratamento das informações para o ViewModel, um pouco parecido com o Presenter. No entanto, a grande diferença é, enquanto o Presenter do MVP conhece a View e tem o papel de "apresentar". No MVVM o ViewModel tem o papel de também conter o tratamento das informações, porém, ele não conhece a View, ocorrendo o contrário, a View conhecendo o ViewModel, ou vários ViewModel's.

Feita a introdução, vamos ao ponto que eu quero chegar. É comum "injetarmos" o ViewModel diretamente na nossa View utilizando o MVVM. E isso me incomoda um pouco, portanto, vamos utilizar o padrão de projeto Factory para desacoplarmos a implementação do ViewModel da nossa View.

Eu aproveitei o excelente conteúdo apresentado no video e fiz um fork do repositório para realizarmos as nossas alterações.

A primeira coisa a ser feita é removermos o useLoginViewModel que estava sendo usado diretamente dentro da nossa View. Como podemos ver no código abaixo:

import useLoginViewModel from './view.model';

const LoginView: React.FC = () => {
  const {email, password, setEmail, setPassword, isLoading, onSubmit} =
    useLoginViewModel();
};

Vamos receber o loginViewModel via props, como o useLoginViewModel retornava o tipo LoginViewModel, então a alteração será mínima. Portanto:

Recebemos loginViewModel via props;

const LoginView: React.FC<Props> = ({loginViewModel}) => {
  const {email, password, setEmail, setPassword, isLoading, onSubmit} =
    loginViewModel;
};

Agora vamos definir um tipo para o loginViewModel, como já mencionado o useLoginViewModel retornava um tipo LoginViewModel, logo:

type Props = {
  loginViewModel: LoginViewModel;
};

Bem, isso feito. Vamos criar o nosso Factory que vai realizar a composição das dependências, ou seja, vamos passar o nosso loginViewModel via props para a nossa View.

import React from 'react';
import LoginView from '../../../pages/login/view';
import useLoginViewModel from '../../../pages/login/view.model';

const loginViewFactory: React.FC = () => {
  const loginViewModel = useLoginViewModel();

  return <LoginView loginViewModel={loginViewModel} />;
};

export default loginViewFactory;

Por fim, agora basta usar o nosso LoginFactory na raiz do App, em vez do LoginView.

import React from 'react';
import LoginFactory from './helpers/factories/login/view.factory';

const App: React.FC = () => {
  return <LoginFactory />;
};

export default App;

E é isso pessoal, com essa abordagem, conseguimos desacoplar da nossa View o ViewModel, passando apenas o tipo LoginViewModel via props, deixando totalmente independente da implementação utilizando um Factory. Ah, e os testes estão passando normalmente sem necessidade de alterações.

Caso tenha interesse em ver o código: https://github.com/MarlonBeloMarques/mvvm-factory-with-react-native

Valeu galera, até a próxima.

Composite - Design Pattern

Marlon Marques — Mon, 31 Oct 2022 22:15:25 +0000

Problema
Imagine o seguinte cenário: sua aplicação possui diversas integrações com plataformas de envio de eventos, todas seguindo o mesmo padrão de conteúdo de envio. Sua aplicação começa a ficar repleta de integrações de envio de eventos como por exemplo: Facebook, Firebase Analytics etc. O que nos leva ao seguinte problema:

Código "redundante", sua aplicação começa a enviar vários eventos com o mesmo padrão de código.
Se por algum motivo você desejar remover/desligar algum evento específico, ou vários eventos ao mesmo tempo, você terá um árduo caminho pela frente.

Esse foi um dos cenários encontrados ao se ter uma aplicação integrada com vários envios de eventos. Estávamos perdendo o controle 🤯.

Solução
Queríamos ter um maior controle sobre os nossos eventos, que vão desde:

Remover a "redundância" de envio de eventos no código;
Controlar os eventos enviados, desde um evento específico à um grupo de eventos;

Em conjunto com a equipe, ao se deparar com o problema, percebemos que a solução do problema se encaixava muito bem no Padrão de Projeto Composite.

Então como podemos resolver o problema usando o Composite?

Primeiro vamos ver a proposta de solução para o problema através de um Diagrama de Classes UML, e assim, discutir um pouco baseando-se nele.

Vamos lá, primeiro vamos começar resolvendo os nossos problemas passo a passo.

De inicio queremos poder enviar eventos de add e de view, através de plataformas como Facebook, Firebase etc. Para isso criamos uma interface EventActions que contém as ações mencionadas, fazendo com que o Facebook e o Firebase respeitem esse contrato.
Porém, como mencionado, queremos poder ter não só eventos por plataformas específicas, mas como também, eventos baseados por escopo. Para isso criamos o Analytics que também respeita o contrato com EventActions. Se pararmos para pensar, o Facebook e o Firebase tem certa relação com o Analytics por se tratarem de eventos de análise. Só que ainda tem um ponto... Precisamos de alguma forma fazer essa referência entre "pai" e "filho". Vamos resolver esse probleminha no próximo passo.
Chegamos a mencionar que queríamos poder desabilitar os eventos quando necessário. Para isso criamos a interface EventStatus, onde ela contém a função de poder desabilitar o evento, todas as nossas classes possuem um contrato com ela também. Mas não só isso, vamos aproveitar para adicionar a responsabilidade de poder atribuir um pai para a classes que respeitam esse contrato, assim, resolvendo o problema mencionado no passo acima.
No entanto, tem algo faltando... Comentamos da possibilidade de poder desabilitar os eventos especificamente ou por características/escopo. Para conseguirmos isso, vamos criar um EventComposite que tem um contrato com EventStatus e EventActions. Além disso, possui também a característica de conter uma lista de eventos.

Acho que agora ficou um pouco mais claro a solução para o nosso problema.

Vamos ver como funciona na prática

Seguindo o passo a passo acima, vamos criar as nossas classes e interfaces, conforme diagrama UML.

Primeiro criamos as nossas interfaces que vão definir as regras que as classes devem seguir.

interface EventActions {
  add(): void
  view(): void
}

interface EventStatus {
  parent?: EventStatus
  readonly isDisabled: boolean

  disable(event?: EventStatus): boolean | void
}

Agora, criamos as nossas classes responsáveis pelo envio de eventos.

class Facebook implements EventActions, EventStatus {
  parent?: EventStatus
  isDisabled: boolean

  disable(event?: EventStatus): boolean {
    this.isDisabled = true
    return this.isDisabled
  }
  add(): void {
    if(!this.isDisabled) {
      console.log('Facebook: add')
    }
  }
  view(): void {
    if(!this.isDisabled) {
      console.log('Facebook: view')
    }
  }
}

class Firebase implements EventActions, EventStatus {
  parent?: EventStatus
  isDisabled: boolean

  disable(event?: EventStatus | undefined): boolean {
    this.isDisabled = true
    return this.isDisabled
  }
  add(): void {
    if(!this.isDisabled) {
      console.log('Firebase: add')
    }
  }
  view(): void {
    if(!this.isDisabled) {
      console.log('Firebase: view')
    }
  }
}

Aqui temos um caso em particular, como o Analytics não é de fato resposável por enviar eventos, e sim, um tipo mais abrangente, a implementação é mínima.

class Analytics implements EventActions, EventStatus {
  parent?: EventStatus
  isDisabled: boolean


  disable(event?: EventStatus | undefined): boolean {
    this.isDisabled = true
    return this.isDisabled
  }
  add(): void {}
  view(): void {}
}

E aqui temos a cereja do bolo, o nosso EventComposite, responsável por realizar a composição dos nossos eventos.

type EventUseCase = EventStatus & EventActions

class EventComposite implements EventActions, EventStatus {
  parent?: EventStatus
  isDisabled: boolean

  constructor(private readonly events: Array<EventUseCase>) {}

  disable(event?: EventStatus): boolean | void {
    if(event?.parent === undefined) {
      this.completeForEachEventsWith((eventOfList) => {
        if(eventOfList.parent === event) {
          eventOfList.disable()
        }
      })
    }

    if(event?.parent) {
      event?.disable()
    }
  }
  add(): void {
    this.completeForEachEventsWith((event) => {
      event.add()
    })
  }
  view(): void {
    this.completeForEachEventsWith((event) => {
      event.view()
    })
  }

  private completeForEachEventsWith(complete: (event: EventUseCase) => void) {
    this.events.forEach((event) => {
      complete(event)
    })
  }
}

Agora vamos brincar um pouco. Aqui criamos os nosso eventos e adicionamos ao nosso composite. Preste atenção quando atribuímos um pai para o facebook e firebase.

const main = () => {
  const analytics = new Analytics();
  const facebook = new Facebook()
  facebook.parent = analytics
  const firebase = new Firebase()
  firebase.parent = analytics

  const composite = new EventComposite([analytics, facebook, firebase])
}

Vamos desabilitar primeiro o facebook e executar o view e add do composite.

 composite.disable(facebook)

 composite.view()
 composite.add()

Saída:

"Firebase: view" 
"Firebase: add"

Agora vamos desabilitar somente o analytics.

 composite.disable(analytics)

 composite.view()
 composite.add()

Saída:

Você pode estar se perguntando, o que aconteceu com a saída? Como o analytics é pai do facebook e firebase, ao desabilitarmos ele, automaticamente desabilitamos os seus filhos. Eis a mágica do Composite 🤌🏻.

Como podemos ver, o Composite é uma boa solução para resolver problemas onde precisamos compor os objetos em um formato de árvore e conseguir tratá-los de forma singular.

Aqui você encontrará o repo do código utilizado como exemplo: https://github.com/MarlonBeloMarques/composite-designpattern

É isso galera, até a próxima.

Utilizando completion handler's para desacoplar suas Aplicações funcionais

Marlon Marques — Tue, 27 Sep 2022 22:31:17 +0000

É muito comum principalmente em Aplicações funcionais como React e React Native, utilizarmos funções dentro de uma função principal. Mas o que há de errado com isso? Não conseguirmos acessá-las de forma isolada, diferente de funções contidas em Classes. É aí que quero chegar.

Levando isso em consideração, é obvio que é muito mais difícil escrever testes unitários de forma isolada para testar sua aplicação. Portanto, queria compartilhar com vocês uma forma de desacoplar sua aplicação contendo cenários onde somos "obrigados" a adicionar funções dentro de uma função principal, e assim conseguir testá-las de forma isolada utilizando completion handler's.

🤔 O porquê desse artigo?
🤓 Como cheguei na solução?
😎 Desacoplando o código
🤯 Testando as funções de forma isolada

🤔 O porquê desse artigo?

Particularmente já observei muito esse cenário de acoplamento em funções envolvendo a navegação no react native. Isso aconteceu comigo recentemente, onde eu queria testar algumas funções isoladamente que continham regras de navegação. Ao tentá-las retirar da função principal e isolá-las para poder testá-las, a aplicação quebrava devido a dependência do navigation.

Vou tentar exemplicar isso através do código:

export default function NotificationListener(navigation: any) {
    const navigateToChat = (id: any, content: any) => {
        if (id && content) {
            navigation.navigate('Chat', { id: id, content: content })
        }
    }

    const goToScreen = (notification: any) => {
        const {
            userId,
            userName,
            userMessage
        } = notification.data

        const content = { userName, userMessage }
        navigateToChat(userId, content)
    }
}

Após me deparar com esse código, e a necessidade de manté-lo testável, decidi que deveria investir esforços para desacopla-lo e conseguir testá-lo. E a solução foi utilizar completion handler's.

🤓 Como cheguei na solução?

Como de fato o que eu realmente queria testar era a regra que permitia a chamada das ações de navegação, e era o que estava me impedindo de desacoplar esse código... Então a primeira medida a ser tomada foi desacoplar o que estava em volta da ação de navegação.

Com isso, a solução se tornou fácil, bastava eu passar via parâmetro uma função que conclua com a navegação.

😎 Desacoplando o código

Antes de começarmos a refatorar o código, vamos ver um passo a passo de como fiz isso:

Criei um arquivo separado chamado NotificationListenerActions, que seria o responsável por ter todos os tipos de ações a serem tomadas ao receber uma notificação.
Movi as funções que realizavam algum tipo de navegação, para o arquivo NotificationListenerActions e as deixei visíveis exportando-as.
Adicionei um parâmetro a mais em todas as funções que finalizavam com a chamada desse parâmetro.
Por fim, em NotificationListener, chamei essas funções e passei via parâmetro a função que concluia com a ação de navegação.

O arquivo NotificationListenerActions ficou mais ou menos assim:

export const navigateToChat = (id: any, content: any, navigation: any) => {
    if (id && content) {
        navigation.navigate('Chat', { id: id, content: content })
    }
}

E o arquivo NotificationListener ficou assim:

export default function NotificationListener(navigation: any) {
    const goToScreen = (notification: any) => {
        const {
            userId,
            userName,
            userMessage
        } = notification.data

        const content = { userName, userMessage }
        navigateToChat(userId, content, navigation)
    }
}

E foi nesse momento que a aplicação quebrou 😵‍💫! Como já mencionei, precisaremos desacoplar a navegação das nossas funções, ou seja, do navigateToChat. Então agora vamos utilizar um completion handler para fazer isso.

export const navigateToChat = (id: any, content: any, completionHandler: (router: string, params: { id: number, content: {userName: string, userMessage: string} }) => void) => {
    if (id && content) {
        completionHandler('Chat', { id: id, content: content })
  }
}

Como pode-se observar, agora em nenhum momento o navigation é mencionado na nossa função navigateToChat. O primeiro passo foi dado, agora vamos chamar essa função corretamente no NotificationListener .

export default function NotificationListener(navigation: any) {
  const navigateTo = (router: string, params: any) => {
    navigation.navigate(router, params)
  }

    const goToScreen = (notification: any) => {
        const {
            userId,
            userName,
            userMessage
        } = notification.data

        const content = { userName, userMessage }
        navigateToChat(userId, content, navigateTo)
    }
}

Explicando um pouco o que fizemos acima. Se você observar, não mudamos muita coisa, apenas o fato de que agora recebemos uma função via parâmetro e que dentro dela realizamos a ação de navegação.

🤯 Testando as funções de forma isolada

E agora finalmente podemos testar nossas regras contidas nas funções de forma isolada. Então vamos ver como ficaria o teste unitário para esse cenário.

describe('NotificationListenerActions', () => {
  test('should not call completionHandler if id and content is empty', () => {
    const completionHandler = jest.fn()
    const id = ''
    const content = {}
    const sut = navigateToChat(id, content, completionHandler)

    expect(completionHandler).not.toHaveBeenCalled()
  })

  test('should call completionHandler if id and content is not empty', () => {
    const completionHandler = jest.fn()
    const id = 'any_id'
    const content = { userName: 'any_userName' userMessage: 'any_userMessage' }
    const sut = navigateToChat(id, content, completionHandler)

    expect(completionHandler).toHaveBeenCalledTimes(1)
  })
})

Como você pode observar, a proposta dos testes unitários não foram testar as ações de navegação, mas sim as regras contidas para realizar tal navegação.

Portanto, através dessa abordagem se torna possível testar as regras contidas nas funções de forma isolada e assim sentir-se seguro na hora da refatoração e implementação do código, nesse caso, ao receber um Push Notification.

É isso aí galera, nos vemos na próxima!

Como implementar uma Cultura de Testes Unitários na sua equipe

Marlon Marques — Sun, 07 Aug 2022 19:58:16 +0000

Por mais que muitos devs conhecam a importância dos testes automatizados e principalmente os testes unitários, ainda é raro encontrar empresas que abraçaram a cultura de testes, onde entregar uma feature com testes unitários é algo imprescindível.

Esse é um cenário ainda muito comum onde temos duas hipóteses: ou os devs não escrevem testes unitários na sua empresa ou não prosperou essa cultura. Isso ocorre frequentemente pela falta de referências na empresa, ou simplesmente porque os lideres etc., acreditam que a entrega contendo testes possam afetar o prazo de entrega de uma tarefa.

Se esse for o caso da segunda hipotese, então temos um grande problema. Convencer o seu líder que entregar tarefas com testes unitários pode trazer grandes benefícios para o time e para a entrega pode ser uma tarefa árdua, e é algo que esse artigo não vai englobar. Até porque eu não passei por isso 😆.

Bem, no meu caso foi um cenário um pouco diferente, ao tomar a iniciativa de trazer a cultura de entrega de tarefas contendo testes unitários. Pudi perceber que anteriormente já tinha-se tentado implementar essa cultura, no entanto, não vingou. Talvez pelos seguintes motivos:

Os testes unitários anteriormente implementados, não testavam de fato as funcionalidades. Pude perceber que escreviam os testes apenas por escrever.
Isso se deu provavelmente pelo fato de não se ter uma referência de boas práticas para escrita de testes no time, assim ocasionando em testes sem sentido.
Por fim, abriram mão da escrita dos testes unitários e começaram a entregar as tarefas sem cobertura de testes. Talvez por não se ter uma boa orientação para escrita de testes, ou por decisão da liderança. Acredito que tenha sido pelo primeiro motivo.

Então como trazemos essa cultura de testes unitários para nossa equipe? Irei falar um pouco sobre o passo a passo que seguimos para retomar com essa cultura de testes unitários.

Primeiramente, porque se perdeu essa cultura de escrita de testes? Como podemos nos planejar para retomar essa cultura.
Sua equipe possui o conhecimento necessário para escrever testes unitários que realmente façam sentido?
Agora que todos os devs da equipe possuem um certo conhecimento sobre testes, como podemos manter essa cultura?

Primeiramente, porque se perdeu essa cultura de escrita de testes? Como podemos nos planejar para retomar essa cultura.

A primeira coisa que devemos fazer é se perguntar porque hoje o time não escreve mais testes unitários. Bem, como já mencionado, no meu caso o motivo é incerto, pude perceber que os testes unitários que continham no projeto não testavam de fato as funcionalidades, e ao conversar com a equipe percebi que a grande maioria não tinha conhecimento sobre testes automatizados. Então obviamente devemos começar por aí.

Antes de começarmos a escrever os testes unitários de fato, devemos pensar como podemos engajar o time para que todos tenham capacidade de começar a escrever testes.

Então ai de fato demos o primeiro passo para trazer essa cultura para o time. Conversando com alguns membros do time, decidimos que a melhor maneira seria implementar os testes unitários em alguma feature que já estava pronta e prestes a ser entregue. O objetivo seria cobrir essa feature de testes unitários e trazer para o time as dores sentidas e a experiência ao testá-la.

O resultado não podia ser diferente, a experiência ao cobrir essa feature de testes unitários trouxe para o time uma boa referência de como deve ser testado um componente, uma classe, função etc. Além disso, nos possibilitou construir uma padrão para que o time pudesse seguir, conseguimos corrigir os testes que antes estavam quebrando e por fim, conseguimos gerar uma documentação bem detalhada contendo uma boa base teórica, exemplos, conceitos e claro o código em si onde foi feito o experimento na feature 🥳🎉.

Sua equipe possui o conhecimento necessário para escrever testes unitários que realmente façam sentido?

Após termos uma boa base e referência para que o time possa começar a escrever testes unitários, ainda tinhamos uma questão, será que o time está realmente preparado para escrever testes?

Após fazer essa reflexão, percebemos que não. Então o próximo passo foi realizar um Workshop sobre testes automatizados focado principalmente na escrita de testes unitários. Esse workshop foi desde a base teórica até a mão na massa, escrevendo testes em conjunto, e o melhor de tudo que a apresentação foi totalmente baseada na documentação que tínhamos escrito anteriormente. Bem, o resultado foi incrível, foram separados dois dias para realizar o workshop durante o nosso horário de trabalho. Ocorreram muitas trocas de ideias, opiniões, debates etc.

Com todo esse processo, acredito que agora realmente o time estava pronto para entregar suas tarefas contendo os testes unitários.

Agora que todos os devs da equipe possuem um certo conhecimento sobre testes, como podemos manter essa cultura?

Foi um processo longo de desenvolvimento, preparação do time para que possamos englobar os testes unitários em nossas entregas. Mas como podemos manter essa cultura para que ela possa se manter e enraizar-se na equipe?

Para essa pergunta eu não tenho a resposta certa, talvez estejamos ainda nessa etapa. O que posso compartilhar com vocês é:

Para os que abraçaram a ideia de entregar as tarefas com testes unitários, tem-se observado os benefícios que os testes trazem. Por mais que tenha-se aumentado o tempo de entrega das tarefas, aos poucos o time tem se acostumado a escrever testes unitários.

Isso é muito bom. Mas para isso, precisamos que alguém carregue essa responsabilidade de manter o time engajado e trazendo os resultados das entregas contendo testes unitários. De inicio você precisa carregar essa responsabilidade e continuar incentivando os demais membros do time. Esse é um processo lento, mas aos poucos o time vai se acostumando a realizar essas entregas. Por fim, aos poucos vamos melhorando essa cultura até que ela se estabilize de fato e todas as entregas só sejam feitas com cobertura de testes.

Essa foi a forma que encontramos de trazer essa cultura para o time, com certeza será um processo longo, mas que pode trazer grandes frutos para o desenvolvimento pessoal do dev e mais confiança na entrega da equipe.

Valeu galera, até a próxima.

Como desacoplar a Navegação no React Native

Marlon Marques — Sun, 17 Jul 2022 20:56:07 +0000

Quando começamos a desenvolver uma aplicação em React Native, umas das coisas primordiais que todo aplicativo tem é a navegação entre telas. Bem, é comum pensarmos que quando falamos em navegação no React Native, já associamos ao React Navigation e já saímos instalando as bibliotecas e criando a estrutura de navegação. Até ai tudo bem, mas o meu ponto aqui é, quando começamos a injetar diretamente as ações de navegação no nosso Presenter.

Esse questionamento se veio de um incômodo pessoal e dúvida, se existem outras bibliotecas que realizam a navegação no React Native, e sim, existem algumas como React Native Navigation by Wix, React Router Native etc.

Então, e se um dia eu desejar utilizar outra biblioteca de navegação sem ser a do React Navigation, o quanto de esforço eu teria pra fazer isso, considerando que as ações de navegação estão acopladas diretamente no meu Presenter?

Para isso, decidi realizar esse experimento em um projeto pessoal utilizando conceitos como TDD e Clean Architecture, onde você pode encontrá-lo aqui. E aproveitei para escrever este artigo.

Esse artigo está divido nas seguintes etapas:

1 🧐. Realmente faz sentido desacoplar a Navegação no React Native?

2 🤓. Montando a estrutura inicial de Navegação com React Navigation

3 😎. Utilizando Camadas para desacoplar o React Navigation da minha Aplicação

4 🤌🏻. Chamando a Ação de Navigate no nosso Presenter

5 🧑🏻‍💻. Escrevendo alguns cenários de Testes Unitários

🧐 Realmente faz sentido desacoplar a Navegação no React Native?

Quando pensamos no trabalho a mais que isso pode trazer no nosso desenvolvimento, pode não fazer sentido desacoplar as ações de navegação do nosso Presenter. Afinal pode existir algum cenário onde eu abra mão do React Navigation para usar outra biblioteca?

Nesse caso, eu acredito que vai depender da decisão do dev, ou do time em conjunto.

Mas se isso um dia acontecer, imagine o trabalho que ia dar trocar em todos os Presenter's a ação de navegar por exemplo 😵‍💫.

Abaixo podemos ver uma comparação utilizando uma Interface de navegação via props, e a forma comum que é utilizar a navegação direta do React Navigation.

type Props = {
  navigate: Navigate;
};

const WelcomePresenter: React.FC<Props> = ({ navigate }) => {
  const buttonAction = () => {
    navigate.navigateToMyPlans();
  };
}

const WelcomePresenter: React.FC<Props> = ({ navigation }) => {
  const buttonAction = () => {
    navigation.navigate(Routes.ACTIVITY);
  };
}

Aparentemente a diferença é quase nula, mas se pararmos para pensar, quando utilizamos o navigation diretamente, criamos uma dependência da navegação que estamos usando.

🤓 Montando a estrutura inicial de Navegação com React Navigation

Então vamos lá, precisamos primeiro deixar o nosso React Navigation configurado. Considerando que você já saiba instalar as bibliotecas necessárias do React Navigation, irei apenas deixar o link para documentação em casos de dúvida.

Primeiro vamos montar o nosso Container de Navegação:

type Props = {
  setNavigationTop: (navigatorRef: NavigationContainerRef<any>) => void;
  initialRouteName: keyof StackParams;
};

const Navigation: React.FC<Props> = ({
  setNavigationTop,
  initialRouteName,
}) => {
  return (
    <NavigationContainer ref={setNavigationTop} theme={DefaultThemes}>
      <StackNavigation initialRouteName={initialRouteName} />
    </NavigationContainer>
  );
};

export default Navigation;

No projeto eu utilizei o tipo de navegação em pilha, então agora vamos configurar a navegação em pilha das nossas telas:

const Stack = createNativeStackNavigator<StackParams>();

type StackNavigationParams = {
  initialRouteName: keyof StackParams;
};

const StackNavigation: React.FC<StackNavigationParams> = ({
  initialRouteName,
}) => {
  return (
    <Stack.Navigator
      initialRouteName={initialRouteName}
      screenOptions={{
        headerTransparent: true,
        headerBackTitleVisible: false,
        headerTintColor: colors.white,
        title: '',
      }}
    >
      <Stack.Screen name={Routes.WELCOME}>
        {(props) => <WelcomeFactory {...props} />}
      </Stack.Screen>
    </Stack.Navigator>
  );
};

export default StackNavigation;

O que falta agora é só adicionarmos o nosso Navigation na raiz da aplicação, então ficaria mais ou menos assim:

type Props = {
  initialRouteName: keyof StackParams;
};

const Main: React.FC<Props> = ({ initialRouteName }) => {
  return (
    <WrapperScreen>
      <StatusBar barStyle="dark-content" />
      <Navigation
        setNavigationTop={(navigationRef: NavigationContainerRef<any>) =>
          setTopLevelNavigator(navigationRef)
        }
        initialRouteName={initialRouteName}
      />
    </WrapperScreen>
  );
};

Legal, essa seria a configuração necessária para termos em nossa aplicação a navegação entre telas. Obviamente não detalhei tanto as importações e os tipos utilizados, até porque não é objetivo deste artigo. Mas se quiser ver os detalhes, você pode encontrar nesse repositório.

😎 Utilizando Camadas para desacoplar o React Navigation da minha Aplicação

Então finalmente chegamos na cereja 🍒 do bolo, aqui vamos quebrar um pouco o rito, e vamos utilizar alguns conceitos como Camadas, Interfaces, Adapters etc.

Para representar esse desacoplamento da ação de navegação, vamos seguir esse diagrama que demonstra as camadas que vamos utilizar.

Mas antes de começarmos, vou explicar rapidamente o diagrama acima, a proposta é desacoplarmos da nossa aplicação dependências externas, como por exemplo o React Navigation, para isso utilizaremos um Adapter. Outro ponto interessante é a camada de Domínio, onde nossa camada de Presentation não conhece nada da camada de Data e Infra, a comunicação entre essas camadas se dá através da camada de Domínio, será ela que utilizaremos no nosso Presenter para realizar as navegações.

Começando pelo Domínio:

export interface Navigate {
  navigateToMyPlans(params?: RouteParams): void;
}

Em direção ao Data:

export class NavigateScreenMyPlans implements Navigate {
  constructor(readonly navigateScreen: NavigateScreen) {}

  navigateToMyPlans(params?: RouteParams | undefined): void {
    this.navigateScreen.navigate(Routes.ACTIVITY, params);
  }
}

export interface NavigateScreen {
  navigate(routeName: string, params?: GenericObject | undefined): void;
}

E somente agora utilizaremos as ações do React Navigation na camada de Infra:

export class ReactNavigationAdapter implements NavigateScreen {
  constructor(readonly navigation: NavigationContainerRef<any>) {}
  navigate(routeName: string, params: GenericObject | undefined): void {
    this.navigation.dispatch(
      CommonActions.navigate({ name: routeName, params: params }),
    );
  }
}

🤌🏻 Chamando a Ação de Navigate no nosso Presenter

Ótimo, agora que o Core da nossa aplicação está pronta. Agora vem a parte mais simples, que é realizarmos a ação de navegar através da nossa camada de Dominio que será passada via props.

type Props = {
  navigate: Navigate;
};

const WelcomePresenter: React.FC<Props> = ({ navigate }) => {
  const [toggleEnabled, componentsToggle] = useState(false);

  const buttonAction = () => {
    navigate.navigateToMyPlans();
  };

  return (
    <Welcome
      buttonAction={buttonAction}
      componentsToggle={componentsToggle}
      toggleEnabled={toggleEnabled}
    />
  );
};

export default WelcomePresenter;

Então se pararmos para observar, em nenhum momento no nosso Presenter, sabemos que estamos utilizando o React Navigation para realizar a navegação. O que estamos utilizando é apenas uma Interface que é passada via props.

Mas em que momento passamos via props? Para isso vamos utilizar um Factory onde nele faremos a composição das dependências necessárias.

type Props = {
  route: RouteProp<StackParams, Routes>;
  navigation: any;
};

const WelcomeFactory: React.FC<Props> = () => {
  const navigate = useNavigate();
  const navigateScreen = new NavigateScreenMyPlans(navigate);
  return <Welcome navigate={navigateScreen} />;
};

export default WelcomeFactory;

🧑🏻‍💻 Escrevendo alguns cenários de Testes Unitários

Por ultimo, mas não menos importante. Vamos ver como se torna mais fácil e claro, os testes unitários envolvendo a navegação.

Como foi utilizado o TDD, todas as camadas envolvendo a navegação possuem testes unitários, mas como o foco aqui é o desacoplamento do React Navigation do nosso Presenter, então vou mostrar somente o teste feito no nosso Presenter.

describe('Presentation: Welcome', () => {
  test('should navigate with success when button press', () => {
    const { sut, navigateToMyPlansSpy } = makeSut();
    const button = sut.getByTestId('button_id');

    fireEvent.press(button);
    expect(navigateToMyPlansSpy).toHaveBeenCalledTimes(1);
  });
});

const makeSut = () => {
  let navigation = {} as NavigationContainerRef<any>;

  render(
    <Navigation
      setNavigationTop={(navigationRef) => (navigation = navigationRef)}
      initialRouteName={Routes.WELCOME}
    />,
  );

  const navigate = new NavigateScreenMyPlans(navigation);

  const navigateToMyPlansSpy = jest.spyOn(navigate, 'navigateToMyPlans');

  const sut = render(<Welcome navigate={navigate} />);
  return { sut, navigateToMyPlansSpy };
};

Como foi feito todo o desacoplamento da navegação, não precisamos mais testar toda a aplicação até chegar no objetivo do teste. Basta criar a navegação e passar o navigate via props.

Bem, chegamos ao final do artigo, queria compartilhar essa ideia com vocês, onde mostro como podemos remover essa dependência direta do React Navigation dos nossos Presenter's e assim termos maior liberdade e facilidade para um dia trocarmos de bibliotecas de navegação sem grandes problemas, além de deixar o nosso Presenter menos acoplado.

Valeu galera, até a próxima.