TDD no desenvolvimento dos projetos?

[wandersoncferreira]

Vocês seguem TDD no desenvolvimento dos projetos de vocês? Se sim, podem compartilhar o workflow utilizado? Vlw

[ericdallo]

Eu sigo em boa parte das vezes, quando ja tem alguma feature que ja existe e precisa de algum fix/improvement, funciona muito bem na minha opiniao, em compensação, uso menos principalmente se uma feature é nova/tenho que criar muitos namespaces ou algo do genero.

[pfeodrippe]

Não sigo exatamente o TDD, o importante parece fazer testes ali no contexto, se é antes ou depois, não importa muito.

Principalmente em Clojure, prefiro muito mais fazer testes de integração do que unitários. Quando se roda um teste, feedback fica tão rápido no REPL que integração fica com tempo de unitário (claro que depende da configuração do sistema também).

TDD parece ser menos importante em Clojure. Testes são importantíssimos! Só tô falando do TDD mesmo.

[pfeodrippe]

O downside é que depende de outros serviços em pé, mas tem que tentar gerenciar isso.

Vocês sofrem com problema de tempo de execução dos testes? Eu acho que nesse caso dos testes de integração seja bem dificil de rodar em paralelo, certo?

Não que eu tenha visto, os projetos em Clojure também não são tão grandes ainda. Mas no job anterior era desse jeito usando apenas testes de integração (datomic em memória) e era de boa (aí dava para paralelizar bem ahahaha).

[pfeodrippe]

(exemplo de algo complexo: um empregado com dois dependentes e um deles menor de 18 anos onde você tem que calcular quanto será o plano de saúde familiar).

Não entendi exatamente por que isso é complexo, mas usamos essa biblioteca aqui https://github.com/reifyhealth/specmonstah para gerar várias entidades no banco de dados de acordo com o que queremos testar, ou seja, cada teste tem acompanhado uma estrutura de banco de dados desejada como premissa para o teste acontecer.

Isso ajudaria o caso que você tem em mente?

Foi só um exemplo de "complexo", não literalmente, foi mal ahahaha. O complexo que eu quis dizer mesmo foi de ter que criar dados intermediários (que são apenas coisas de implementação) para testar uma função. E eu gosto de usar o rails architecture, acho mais fácil de ler o que está acontecendo, mas as funções recebem um mapão com bastante coisa e isso incomoda um pouco com testes unitários.

Mas gostei da library para outros casos de uso, parece ser interessante e esperta :D

[wandersoncferreira]

Saquei, saquei!

E eu gosto de usar o rails architecture, acho mais fácil de ler o que está acontecendo, mas as funções recebem um mapão com bastante coisa e isso incomoda um pouco com testes unitários.

Também uso railsway-oriented com a biblioteca rop. Mas faço a seguinte distinção:

domain/empregado.clj
web/
web/specs/
web/handlers/criar_empregado.clj

As funções rop só existem em namespaces handlers e esses namespaces não tem nenhum teste unitário, somente integração. Quando alguma função mais complexa é necessária, isso é movido para os namespaces dentro de domain e referenciado por uma rop. Em domain tem teste unitário.

Assim as rops são literamente "glue code".

[luciolucio]

Por que você acha que TDD parece ser menos importante em Clojure?

[pfeodrippe]

@luciolucio Esse fluxo que tu falou em #15 (comment) é o que estou chamando de TDD. Nesse fluxo você tem fast feedback se a coisa está funcionando ou não, o fast feedback você já tem com o REPL IMHO.

Mas talvez não seja importante pra mim então, pode ser que tu seja mais confortável com esse fluxo e tudo bem :)

[luciolucio]

Uso pra tudo e recomendo pra todo mundo. O workflow que eu uso é o comum do TDD - escrever um teste, ver ele falhar, fazer ele passar, refatorar.

[wandersoncferreira]

Legal, você usa alguma biblioteca especifica para auxiliar nisso ou apenas o clojure.test nativo?

[luciolucio]

Em geral só clojure.test nativo mesmo!