SmallBDD announcement

cucumber

SmallBDD.png

SmallBDD é um nascente framework implementado em Smalltalk inspirado no Cucumber.

Smalltalk é uma linguagem onde a expressividade de uma DSL interna dispensa a complicação associada ao desenvolvimento de DSL externas envolvendo o uso de parsers.

Para executar os cenários descritos acima o desenvolvedor implementa as definições (step definitions no jargão do Cucumber) como abaixo:

SmallBDD2SmallBDD3

O projeto está publicado no Smalltalkhub.

Nota: Estou me baseando principalmente na edição de 2012 do The Cucumber Book.

hwcuc_xlargecover

Meu retorno ao BDD (Veja outros posts meus sobre o BDD), cujo valor para equipes interagindo com usuários do negócio me parece inegável, vem também de ver algum valor para organizar o trabalho mesmo quando temos que simular os interesses de usuários abstratos, na Internet por exemplo.

O Akita escreveu um artigo interessante e crítico sobre BDD. Na época fiquei um pouco influenciado em uma espécie de  Cargo Cult. Afinal era o Akita e o DHH! Mas acho que o artigo do Akita está datado e um tanto equivocado. Para criticar ele mostra códigos da step definitions, que são ilegíveis para o negócio realmente. Mas no livro citado acima a parte em que o negócio deve participar da redação é bem mais legível e este é um dos objetivos principais: legibilidade, clareza e simplicidade.

Dentro deste meu novo convencimento resolvi implementar BDD na minha linguagem preferida.

Links relacionados:

  • Writing Maintainable Automated Acceptance Tests, Dale H. Emery
    • Test automation is software development . This principle implies that much of what we know about writing software also applies to test automation. And some of the things we know may not be apparent to people with little or no experience writing software.
    • Much of the cost of software development is maintenance—changing the software after it is written. This single fact accounts for much of the difference between successful and unsuccessful test automation efforts. I’ve talked to people in many organizations that attempted test automation only to abandon the effort within a few months. When I ask what led them to abandon test automation, the most common answer is that the tests quickly became brittle and too costly to maintain. The slightest change in the implementation of the system—for example, renaming a button—breaks swarms of tests, and fixing the tests is too time consuming.
    • But some organizations succeed with test automation. Don’t they experience maintenance costs, too? Of course they do. An important difference is that where unsuccessful organizations are surprised by the maintenance costs, successful organizations expect them. The difference between success and failure is not the maintenance costs per se, but whether the organization expects them. Successful organizations understand that test automation is software development, that it involves significant maintenance costs, and that they can and must make deliberate, vigilant effort to keep maintenance costs low.
Anúncios

Um comentário

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s