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

Pitch: Criei um framework de testes para Go inspirado no Jest

Faz um tempo que venho desenvolvendo em Go e sempre tive uma pulga atrás da orelha com o output do go test. Ele funciona, mas é cru — sem cores, sem contexto, sem aquela sensação de que você sabe exatamente o que quebrou e por quê.

Quem já usou Jest sabe o que estou falando. Aquele output verde e vermelho, o snippet de código apontando exatamente para a linha que falhou, o sumário no final. É uma experiência que te deixa confiante no que está testando.

Então decidi construir isso para o Go. O resultado é o gest.


Como fica na prática

Você escreve seus testes assim:

// calculator_spec.go
func init() {
    calc := Calculator{}
    s := gest.Describe("calculator")

    s.It("adding 2 + 2 should return 4", func(t *gest.T) {
        t.Expect(calc.Add(2, 2)).ToBe(float64(4))
    })

    s.It("dividing by zero should return an error", func(t *gest.T) {
        _, err := calc.Divide(10, 0)
        t.Expect(err).Not().ToBeNil()
    })

    gest.Register(s)
}

E o main.go não precisa nem saber quais arquivos de teste existem:

func main() {
    gest.RunRegistered()
}

Roda com go run . e você vê isso no terminal — com cores, ✓ e ✕, tempo de cada teste e sumário no final.

gest passing tests output

Quando um teste falha, a mensagem é descritiva igual ao Jest:

gest failure message with code snippet

Também tem uma tabela de coverage com go run . -c — com barras de progresso no estilo do pip, arredondadas e coloridas por threshold.

gest coverage table with pip-style progress bars


Detalhes técnicos

Auto-discovery via init() — cada _spec.go se registra sozinho. Adicionar um novo arquivo de testes é só criar o arquivo, sem tocar em nada mais.

Por que _spec.go e não _test.go? O sufixo _test.go é reservado pelo toolchain do Go para go test. O gest usa go run, então qualquer outro sufixo funciona.

Zero dependências — stdlib pura. O gest inteiro é um único arquivo .go que você importa.

Snippets de código — em tempo de execução, o gest lê o arquivo fonte e exibe as linhas ao redor da falha usando runtime.Caller. É assim que a seta ^ aparece apontando para o argumento exato.


O que tem hoje (v0.1.0)

10 matchers: ToBe, ToEqual, ToBeNil, ToBeTrue, ToBeFalse, ToContain, ToHaveLength, ToBeGreaterThan, ToBeLessThan, ToBeCloseTo — todos suportam .Not().


Instalação

go get github.com/caiolandgraf/gest

O repositório tem uma pasta example/ com um projeto funcionando para você rodar na hora.


Feedback, issues e PRs são muito bem-vindos. Se você usa Go e sentiu falta de uma DX melhor nos testes, espero que o gest ajude. 🧪

GitHub: https://github.com/caiolandgraf/gest

Carregando publicação patrocinada...
1

Fala, caiolandgraf!

Cara, que projeto necessário. O go test é robusto, mas a sensação de rodar um teste e ter um feedback visual imediato e legível (esse 'feeling' do Jest) faz toda a diferença na produtividade e na saúde mental de quem está debugando às 2 da manhã.

Gostei muito da abordagem de manter zero dependências e usar o init() para o auto-discovery. É o tipo de simplicidade técnica que a gente valoriza muito na comunidade.

Aproveitando o gancho de ferramentas feitas com alma e foco em soberania digital, queria te convidar para conhecer a crom.run.

Estamos construindo um ecossistema focado em soberania digital e ferramentas local-first (temos desde gerenciadores de arquivos até linguagens que transpiliam para Go). Acho que o seu mindset de melhorar o ferramental base do dev tem tudo a ver com o que estamos fomentando por lá. Fica o convite para conhecer.

Parabéns pelo gest. 🚀