Executando verificação de segurança...
1

NodeJS | Como utilizar TDD no processo de desenvolvimento

NodeJS | Como utilizar TDD no processo de desenvolvimento

Como os testes podem salvar o seu tempo procurando bugs...

Como todos nós sabemos o processo de desenvolvimento é algo que exige planejamento e muita calma para evitar erros indesejados. Para evitar esse tipo de coisa, foram criadas formas de testarmos as aplicações de forma eficiente, e que não exigissem que o desenvolvedor fizesse testes de forma manual, com isso surgiram os testes automatizados que estão presentes em grande parte de todas as linguagens de programação da atualidade.

TDD

TDD ou Test Driven Development é um design pattern que surgiu no início dos anos 2000, com o propósito de tornar o desenvolvimento de software mais seguro a bugs e popularizar a prática de testes nas aplicações.

  1. O primeiro passo é desenvolver o teste, onde logicamente, o teste não irá passar, por não haver a implementação da feature.

  2. No segundo passo deve se desenvolver a nova feature com o propósito da mesma passar no teste.

  3. O terceiro e último passo é refatorar o código, retirando algumas redundâncias que podem ter sido cometidas no processo de implementação.

TDD

No NodeJS, isso pode ser feito na maior parte dos frameworks, tanto front-end, quanto back-end de forma simples. Para isso podemos nos utilizar de bibliotecas como Jest, Vitest, ou nas versões mais recentes do NodeJS, o módulo nativo Test.

Abaixo temos um exemplo de teste automatizado utilizando TDD e Jest:

1. Implementação do teste

    // soma.spec.ts 
    
    describe("Teste de soma", () => { 
        it("Deve ser possível fazer uma soma de 2 números", () => { 
            const resultado = soma(2 + 2); 

            expect(resultado).toBe(4); 
        }) 
    }) 

    // O teste não irá passar pois não existe a definição da função soma(). 

2. Implementação da feature

    // soma.ts 

    export function soma(a: number, b: number) { 
        return a + b; 
    } 
    // soma.spec.ts 

    import { soma } from './soma' 

    describe("Teste de soma", () => { 
        it("Deve ser possível fazer uma soma de 2 números", () => { 
            const resultado = soma(2 + 2); 

            expect(resultado).toBe(4); 
        }) 
    }) 

    // O teste irá passar, pois o resultado esperado pelo teste foi satisfeito.  

3. Refatoração

Neste exemplo, uma refatoração não é necessária pela simplicidade do código.


Conteúdo TDD na prática

Carregando publicação patrocinada...
1

Nos dias atuais onde engenharia é achar o balanço perfeito entre tempo, custo e entrega, tu não acha que o TDD se torna inviavel ou as vezes deixa o código pior do que deveria ser?
Ao meu ver, tu criar um teste antes mesmo de implementar e começar uma nova feature me parece que você esta limitando a própria criatividade só pra fazer o negócio ficar verde, sem contar em um possível erro na concepção do teste por si só.
TDD também é código, tu acha que esse custo a mais é de fato benéfico? Por que não adotar a estratégia de BDD ao invés de TDD?

1

A curto prazo o TDD é sim perda de tempo. Mas a médio e longo prazo ele se paga.

Esse codigo extra se torna parte da documentação do teu código, e evita que futuras alterações quebrem um comportamento previsto.

Talvez perda de tempo seja testar 100% previamente. 70% já é bem viável.