Why You Should Test Your Requirements

We’ve written before about several characteristics of well written requirements, and one of those characteristics is testability. Ahamad has written an list of 10 tests of requirements, with an emphasis on assessing the testability of the requirements. The testability of the requirement determines if the resultant product can be tested to determine if it meets the requirement. (…)

Generated Tests and TDD

TDD has become quite popular, and many companies are attempting to adopt it. However, some folks worry that it takes a long time to write all those unit tests and are looking to test-generation tools as a way to decrease that burden.

The burden is not insignificant. FitNesse, an application created using TDD, is comprised of 45,000 lines of Java code, 15,000 of which are unit tests. Simple math suggests that TDD increases the coding burden by a full third!

Of course this is a naive analysis. The benefits of using TDD are significant, and far outweigh the burden of writing the extra code. But that 33% still feels “extra” and tempts people to find ways to shrink it without losing any of the benefits. (…)

Saudações!
Já que o WordPress não nos dá a possibilidade de colocar enquetes no site, colocamos no site A Maldita Comédia mesmo!!!

Eu e o Ivan queremos melhorar o conteúdo do site, e com o número grande de pessoas que acessam aceitamos o desafio de perguntar a todos: O que temos que melhorar?!

Votem! Conto com a sinceridade e a compreensão de todos que queremos realmente gerar conteúdo de qualidade!

Obrigado!

(Aviso! Esta não é mais uma nova técnica de programação)

Um dos maiores obstáculos na adoção do Desenvolvimento Orientado a Testes, ou Test Driven Development (TDD) é justamente o termo “teste”.

Talvez tenha sido uma bola fora do Kent Beck ter colocado este nome, já que a principal vantagem desta abordagem não é validação de código e sim seu uso para projetá-lo. Como diz o Ron Jeffries, “o objetivo do TDD é escrever um código limpo e que funcione”, ou seja, usamos TDD para nos ajudar escrever código, e não simplesmente testá-lo.

Felizmente este problema de vocabulário não impediu a popularizacão da técnica, porém frameworks como o jUnit continuaram batendo na tecla dos “testes” usando termos como TestCase, TestSuite e obrigando ao programador começar todos os métodos com “test”. Isso colaborou ainda mais na associação de TDD com validação, ao invés de especificação.

Quando escrevemos um “teste” antes de sequer termos a implementação, estamos especificando o comportamento esperado do nosso código, definindo um contexto de entrada e avaliando se as saídas são as esperadas. Esta especificação automatizada, embora de baixo nível, ajuda principalmente na implementação do código, além de servir como ferramenta de validação.

Para tentar desassociar TDD apenas ao conceito de testes, surgiu o termo Behaviour Driven Development (BDD), ou Desenvolvimento orientado a Comportamento. Também foram criados frameworks como o jBehave e RSpec para popularizar um novo vocabulário, mais condizente com os principais benefícios de TDD.

Alguns exemplos deste novo vocabulário incluem:

• Context ao invés de TestCase
• Specification ao invés de Test
• Should ao invés de Assert

Quem já esteja acostumado com TDD e sabe exatamente o que esta técnica compreende talvez continue usando os seus termos, mas muitas confusões seriam evitadas se adotássemos este novo vocabulário.

Para quem quiser saber mais sobre BDD:

• Portal de BDD
• Dave Astel apresentando BDD
• Framework para Java – jBehave
  
• Framework para Ruby – RSpec