TDD em Kotlin: escrevendo código sem medo e sem culpa

Por que o TDD não é apenas mais uma metodologia da moda, mas sua nova capa de super-herói

Imagine: você escreve código como um artista — pincelada por pincelada, linha por linha. Você tem certeza de que tudo é genial. Mas passa uma hora, você executa o aplicativo e ele falha com um erro que você passaria meio dia procurando. Familiar?

Agora imagine outro cenário. Você primeiro escreve um teste que certamente falhará. Depois — o código mínimo para o teste passar. E só então — você refatora, melhora, mas já com a consciência limpa. Isso é o desenvolvimento orientado a testes (TDD), e em Kotlin ele se torna um verdadeiro prazer.

Neste artigo, não vamos dar aulas chatas. Vamos pegar um exemplo real, percorrer todos os três estágios do TDD (Red — Green — Refactor) e mostrar como escrever código confiável sem medo e sem culpa. Pronto? Vamos lá!

TDD: três letras que mudarão seu código

TDD (Test-Driven Development) não é apenas uma técnica, é uma filosofia. A essência é simples: primeiro o teste, depois o código. Parece loucura? À primeira vista — sim. Na prática — economiza horas de depuração.

O ciclo do desenvolvimento orientado a testes

• Red — escrevemos um teste que não passa (ele deve falhar).
• Green — escrevemos o código mínimo para o teste passar.
• Refactor — melhoramos o código sem alterar seu comportamento.

E assim — em ciclo, em pequenos passos. Cada passo é a certeza de que você não quebrou nada. Em Kotlin, com sua sintaxe concisa e segurança contra nulos, o TDD se torna ainda mais agradável.

Ferramentas: o que você precisa para TDD em Kotlin

Antes de mergulhar no código, vamos preparar o arsenal. Para teste unitário em Kotlin, você precisará de:

• JUnit 5 — o padrão de fato para testes unitários.
• MockK — biblioteca para mocks, criada especialmente para Kotlin (chega de problemas com null e companion object).
• Gradle ou Maven — para gerenciamento de dependências.

Adicione no build.gradle.kts:

dependencies {    testImplementation("org.junit.jupiter:junit-jupiter:5.10.0")    testImplementation("io.mockk:mockk:1.13.8")}

Pronto. Agora podemos escrever código que não envergonha mostrar aos colegas.

Escrevendo o primeiro ciclo TDD: uma calculadora ambiciosa

Vamos começar com o clássico — uma calculadora. Mas não uma simples, e sim com suporte a operações com strings. Tarefa: a função calculate recebe uma string no formato "2 + 3" e retorna 5.

Passo 1: Red — escrevendo um teste que falha

Criamos a classe de teste:

import org.junit.jupiter.api.Testimport org.junit.jupiter.api.Assertions.assertEquals

class CalculatorTest {

    @Test    fun `deve somar dois números`() {        val calculator = StringCalculator()        val result = calculator.calculate("2 + 3")        assertEquals(5, result)    }}

Executamos — o teste falha, porque a classe StringCalculator ainda não existe. Sinal vermelho — tudo conforme o planejado.

Passo 2: Green — código mínimo para passar

Escrevemos exatamente o suficiente para o teste passar. Nenhum refinamento arquitetural:

class StringCalculator {    fun calculate(expression: String): Int {        val parts = expression.split(" + ")        return parts[0].toInt() + parts[1].toInt()    }}

Agora o teste está verde. Viva! Mas o código ainda é feio — ele é feito apenas para somar dois números.

Passo 3: Refactor — deixando o código bonito

Refatoramos, mas sem alterar o comportamento. Adicionamos suporte a diferentes operações, extraímos a lógica para funções separadas:

class StringCalculator {    fun calculate(expression: String): Int {        val (a, op, b) =