As Três Leis do TDD

 

Já enumerei as principais razões para utilização da metodologia de Desenvolvimento Orientado a Testes neste artigo (link) e também como praticar em sessões de Coding Dojo neste outro artigo (link), dessa vez quero abortar as leis do TDD (Test Driven Development), essas leis que podemos entender como regras são fáceis de entender e principalmente nos fornecem uma forma simples de validar o que estamos fazendo.

Essas regras foram definidas por Robert C. Martin (Tio Bob), principalmente no intuito de auxiliar no processo de iniciação na utilização da metodologia TDD, essas três regras são mecânicas, você deverá aplicá-las porque irá lhe forçar a escrever código de melhor qualidade e aumentará a facilidade de manutenibilidade.

Lei 1: Você não pode escrever nenhum código fonte, antes de escrever uma especificação de teste que falhe

Isso quer dizer basicamente, o principal e o óbvio para a metodologia, nenhum código pode ser criado, ou classes, ou interfaces, ou seja nada, antes que a especificação do testes seja escrita e falhe, que obviamente irá falhar porque não tem nenhum código para ser validado.

Lei 2: Você não pode escrever mais do que um teste para falhar (e não compilar é falhar)

Muitas vezes já queremos adiantar todas as possíveis soluções e cenários plausíveis para garantir que o que iremos desenvolver irá cobrir os testes e atendendo os resultados esperados, porém esses testes não são testes unitários, são especificação de testes de comportamento, ou seja, você terá que primeiro escrever uma especificação de teste, essa especificação falhará, você então irá codificar para passar no teste e só depois você poderá escrever uma nova especificação de teste para um novo comportamento, dessa forma a cada nova especificação, codificação, estará sendo criado uma pilha de testes que continuaram sendo validados sobre o que está sendo desenvolvimento com qualidade e sem quebras.

Lei 3: Você não pode escrever código fonte mais do que o suficiente para passar no teste que está falhando

Essa talvez seja a regra mais difícil de executar, porque como programador é natural durante o processo de implementação, já tentamos adiantar passos e prever condicionais, situações e comportamentos, porque dessa forma conseguimos escrever códigos que aceleram a implementação final, porém a metodologia nos obriga a dar um passo de cada vez para que possamos ter ciência e principalmente cobertura de todo o processo, com isso fica bem claro que o código fonte que devemos implementar tem que ter o propósito de fazer o teste ser passado e somente isso. Um exemplo básico para ilustrar, caso escreva um teste que precise validar a soma de dois valores (exemplo 1 e 3), sua função deve simplesmente retornar 4, isso fará o teste passar. O motivo por trás disso é forçar você a pensar e dar pequenos passos e ser muito mais produtivo do que tentar codificar em grandes etapas.

Essas três leis podem parecer simples e talvez irão criar um processo moroso inicialmente, entretanto a principal função do TDD é garantir qualidade de código gerado e principalmente cobertura de testes focadas na solução do problema. Ter implementações menores oferecem um poder de concentração maior num único ponto, o que potencializa sua capacidade de resolver o centro do atual problema, com o ponto resolvido, você passa para o próximo e assim até o final. É exatamente para isso que servem essas três leis.

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

TDD no SQL com tSQLt

 

A utilização de teste é uma realidade muito comum no desenvolvimento de aplicativos, porém banco de dados é tratada como uma forma de exceção quando falamos da utilização do método desenvolvimento orientado a testes, principalmente pela falta de uma ferramenta integrada que possibilite a criação de testes, classes, além da metrificação dos resultados da execução dos testes.

O tSQLt é uma ferramenta que oferece uma estrutura de testes para ser aplicado em banco de dados SQL, o tSQLt permite implementar testes de unidade em T-SQL, também fornece recursos como: testes dentro das transações, agrupamento dos testes em classes, saída em texto simples ou XML e o principal de criar clonar de tables, views, functions e procedure para utilizar em simulação nos testes sem interferir nas estruturas reais.

O processo para utilização é bem simples e vamos demonstrar desde a instalação e criação de um teste e sua execução.

1. Instalação do tSQLt

• Baixe tSQLt do site tSQLt.ORG

• Acesse ou crie um novo banco de dados

• Execute o script tSQLtClass.SQL no banco de dados

Installed at 2020-10-24 18:23:21.390

+-----------------------------------------+

|                                         |

| Thank you for using tSQLt.              |

|                                         |

| tSQLt Version: 1.0.5873.27393           |

|                                         |

+-----------------------------------------+

2. Efetuar a criação de “Classes” para agrupar o teste

EXEC tSQLt.NewTestClass 'UnitTestClass';

Esse comando irá criar uma classe que poderá ser utilizada para executar somente os testes que estiverem associadas à ela, na prática o SQL criará um “Schema” com esse nome.

3. Criando um teste

CREATE OR ALTER PROC [UnitTestClass].[Test Exists Function CalculateBestQuote]

AS

BEGIN

  --Arrange

 

  --Act

  

  --Assert

   EXEC tSQLt.AssertObjectExists @ObjectName = N'fnCalculateBestQuote'

END

GO

Importante, toda procedure que representa um teste deve obrigatoriamente iniciar com a palavra “Test”, como o banco de dados podem conter estrutura que podem não existir, diferente de código estático, existe um Assert específico que efetua a validação da existência do objeto, no caso do exemplo, ele está verificando se a function “fnCalculateBestQuote” existe no banco de dados.

4. Executando os testes

   EXEC tsqlt.RunTestClass 'UnitTestClass'

Através do comando, todos os testes que estão associados a classe referida, será executado exibindo as mensagens de erros, os resultados esperados e um resumo dos testes.

[UnitTestClass].[Test Exists Function CalculateBestQuote] failed: (Failure) 'fnCalculateBestQuote' does not exist

 

+----------------------+

|Test Execution Summary|

+----------------------+

 

|No|Test Case Name                                           |Dur(ms)|Result |

+--+---------------------------------------------------------+-------+-------+

|1 |[UnitTestClass].[Test Exists Function CalculateBestQuote]|    127|Failure|

-----------------------------------------------------------------------------

Msg 50000, Level 16, State 10, Line 1

Test Case Summary: 1 test case(s) executed, 0 succeeded, 1 failed, 0 errored.

-----------------------------------------------------------------------------

5. Criando a function 

CREATE OR ALTER FUNCTION fnCalculateBestQuote

(

    @BaseValue decimal(10,2),

@Fator decimal(6,2)

)

RETURNS Decimal(15,2)

AS

BEGIN

    RETURN @BaseValue / @Fator * 2;

END

GO

Após a execução dos testes e da falha, devemos escrever o código que satisfaça a regra de negócio esperada.

6. Executando o teste novamente

EXEC tsqlt.RunTestClass 'UnitTestClass'

O resultado dos testes será com sucesso

+----------------------+

|Test Execution Summary|

+----------------------+

 

|No|Test Case Name                                           |Dur(ms)|Result |

+--+---------------------------------------------------------+-------+-------+

|1 |[UnitTestClass].[Test Exists Function CalculateBestQuote]|      6|Success|

-----------------------------------------------------------------------------

Test Case Summary: 1 test case(s) executed, 1 succeeded, 0 failed, 0 errored.

-----------------------------------------------------------------------------

Portanto, agora ficará mais fácil detectar bugs antes mesmo de conectar com seu código de backend, simplesmente executando os testes no banco de dados.

Existem várias funções desenvolvidas para validações, além claro da parte de clonar tabelas e afins para criar massa de testes, existe uma vasta documentação em https://tsqlt.org/full-user-guide/

Na GFT praticamos TDD em sessão de Coding Dojo que ocorrem a cada 15 dias em sessões online, elas são abertas para todos participarem, basta acessar //meetup.com/GFTBrasil, escolher o melhor dia e horário para você praticar.

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Principais Motivos para Adoção de Desenvolvimento Guiado por Teste (TDD)

Cada metodologia tem suas vantagens para adoção, a TDD (Test-Driven Development ) oferece uma técnica simples que pode garantir a qualidade de entrega e principalmente a segurança nas alterações realizadas no código após sua implementação.

A técnica dessa metodologia é escrever os testes primeiro e depois codificar, dessa maneira você irá se preocupar em pensar em cenários de aceitação, como entrada e saída para atender requisitos de funcionalidade, antes de efetivamente implementá-los. 

Tudo Terá um Teste Afinal

Tudo que precisa ser criado deverá começar pelo teste, para que possamos criar os testes, precisamos ter pleno entendimento da implementação para escrever os testes que precisaram ser validados para atender os requisitos. Outro ponto, é que os testes são evolutivos, devemos escrever um teste, efetuar a implementação, verificação seu resultado positivo, melhorar o código, testar o resultado, escrever um novo teste, implementar a solução, verificar seu resultado e assim por diante. Se durante o processo de uma nova implementação ou melhoria algo quebrar, os testes anteriores vão apontar e tudo deverá ser validado antes de darmos continuidade.

Redução de Código Complexos

Muitas vezes escrevemos códigos que acabam ficando imutáveis, ou seja, uma vez que funcionou ficamos com receio de alterá-lo e acabar quebrando o que está funcionando. Tendo uma fundação baseada em testes, podemos tranquilamente analisar o código para efetuar sua refatoração para simplificá-lo ou ainda performá-lo, sem a preocupação que ao final ele poderá quebrar algo, porque os testes vão garantir sua aderência. Outro fator positivo é que os testes não serão escritos para atender a codificação e sim cenários de negócios, como consequência teremos mais códigos testáveis.

Simplicidade em Primeiro Lugar

Todo desenvolvedor tem o deve ter como parte principal do seu trabalho planejar a implementação, e sem dúvida alguma sendo feito esse planejamento da forma mais simples e objetiva possível o resultado será praticamente a perfeição, já dizia Leonardo da Vinci, "Simplicidade é o último grau de sofisticação".  Quando definimos iniciamos pelo teste que precisa ser validado, temos que pensar na implementação mais simples que atende os requisitos e caso a solução não seja simplista no primeiro momento, podemos melhorá-la num próximo ciclo garantido a qualidade da execução.

Código Refatorados com Segurança

Muitas vezes temos que alterar códigos de terceiros, ou os nossos próprios, e não se sentimos confortáveis em garantir que nada irá parar de funcionar, contudo, se essa rotina contiver testes que foram escritos exclusivamente pensando em atender os requisitos de negócio, podemos tranquilamente efetuar alterações e aplicar os testes para validá-los, com isso qualquer alteração fica praticamente segurança em fornecer a garantia de sucesso na sua implementação.

Basicamente, o ciclo do TDD é escreva o teste, implemente um código para fazer o teste ser válido e melhore o código sem quebre nenhum teste. Repita esse ciclo até que sinta-se todos os requisitos foram testados e atendidos.

Para um cenário onde um desenvolvedor deve garantir seu produto final, ou seja, a codificação de uma necessidade, essa metodologia oferece muitos fatores positivos para facilitar a entrega e também garantir a qualidade, é um paradigma começar por algo que não seja o código, porém após um período de adaptação você verá como é mais simples e funcional utilizar o método Test-Driven Development (TDD).

Marcelo Goberto de Azevedo
Arquiteto na GFT Brasil
//marcelogoberto.com.br