Coding Dojo Floripa

Desenvolvimento Ágil

Arquivos para a Categoria ‘TDD’

Tudo sobre TDD

Publicado por Victor Hugo Germano em Segunda-feira, Setembro 10, 2007

Saudações!
Conversando com Ivan, resolvemos criar um post que agregasse o máximo possível de informações úteis sobre TDD, para que possamos avançar nos encontros do CodingDojoFloripa, efetivamente evitando o que houve no último encontro. Assim, compilei uma série de links que tratam do assunto, basicamente escritos aqui no DojoFloripa, com algumas referências externas, também bastante úteis.

Nossa idéia, a partir de agora, é fornecer informações para que no próximo dojo, não precisemos iniciar toda a conversa sobre tdd novamente, garantindo a evolução contínua da complexidade dos encontros. Portanto, aproveitem!! =)

O que é TDD?

Miscelânia:

Videos:

TDD na prática:

Técnicas:

Livros:

Tentaremos manter esse post sempre atualizado e acessível para que todos possam desgrutar do conteúdo. Se você possui alguma referência, entre em contato!

Publicado em Dojo, Geral, Programming, TDD, eXtreme Programming | 17 Comentários »

CppUnit e o Borland C++ Builder 6

Publicado por Victor Hugo Germano em Quinta-feira, Setembro 6, 2007

Post originalmente inserido em A Maldita Comédia, com o mesmo título. Segue a transcrição do post, que achei bastante pertinente inserir no CodingDojoFloripa.

Bem, como vocês já sabem, estou em uma nova empresa, a Audaces. Em princípio trabalharei com integração contínua, e estou no momento fazendo testes com o ambiente da Borland. É um mundo completamente novo para mim, e estou bastante animado com os resultados! C++!! Segue abaixo um pequeno(e simples) tutorial sobre como iniciar seus testes utilizando Borland C++ Builder 6.

Configuracao de ambiente para testes utilizando o CPPUnit e Borland C++ Builder 6 (BCB6)

Referências:

Requisitos:

Instalação

Será apresentada a utilização do cppUnit para o C Builder através da criação de uma aplicação simples. Seguem os passos para tal:

1. Descompactar CPPUnitBCB6 (Ex: C:\CPPUnitBCB6)

2. Iniciar um projeto novo no BCB (File> New >Application)

2.1 Vincular ao projeto os Headers relativos ao CppUnit.
Faça isso adicionando os diretórios ao projeto em “Project> Options> Directories/Conditionals >Include path”
Selecione os diretórios:

  • %cppunit_dir%\borland\TestRunner
  • %cppunit_dir%\test\textui
  • %cppunit_dir%\test\framework
  • %cppunit_dir%\test\framework\extensions

2.2 Remover o formulário inicial (Form1) em “Project> Remove from Project…> Unit1.cpp”

3. Bibliotecas:

3.1 Adicione ao projeto as bibliotecas do CppUnit em “Project>Add to Project…”

  • %cppunit_dir%\bin\culib.lib
  • %cppunit_dir%\bin\TestRunnerDlg.lib

3.2 Copie a dll existente em: %cppunit_dir%\bin\TestRunnerDlg.dll para dentro do diretório do projeto

4. Crie uma classe de testes Simples:

A primeira classe a ser criada será chamada de FirstTest. Iniciaremos por seu Header, que deve extender a classe TestCase. É necessário declarar os métodos setUp() e tearDown() para que o funcionamento ocorra normalmente.

#ifndef FIRST_TEST_H
#define FIRST_TEST_H

#include "TestCase.h"
#include "TestCaller.h"

class FirstTest: public TestCase
{
public:
    FirstTest(std::string name);
    void setUp();
    void tearDown();
    static Test *suite();
protected:
    void testAssertTrue();
    void testAssertFalse();
    void testFalhara();
    void testAssertMaisUmExemplo();
};

typedef TestCaller<firsttest>
               FirstTestCaller;
#endif

.Abaixo segue a implementação dessa classe. FirstTest.cpp

#include "FirstTest.h"
#include "TestSuite.h"

FirstTest::FirstTest(std::string name): TestCase(name) {
}

void FirstTest::setUp() {    }

void FirstTest::tearDown() { }
Test* FirstTest::suite() {
// All tests have to be explicity added to TestSuite to be executed
TestSuite *suite ;
suite = new TestSuite("nameFirstTest");
suite->addTest(
    new FirstTestCaller("assert True", &FirstTest::testAssertTrue));
suite->addTest(
    new FirstTestCaller("assert False", &FirstTest::testAssertFalse));
suite->addTest(
    new FirstTestCaller("teste que falha", &FirstTest::testFalhara));
suite->addTest(
    new FirstTestCaller("teste equals", &FirstTest::testAssertMaisUmExemplo));
return (suite);
}

void FirstTest::testAssertTrue()
{
assert( true );
}

void FirstTest::testAssertFalse()
{
assert( !false );
}

void FirstTest::testFalhara()
{
assert( false );
}

void FirstTest::testAssertMaisUmExemplo()
{
assertDoublesEqual(0, 0, 0);
}

6. Testando o funcionamento do CppUnit:

O método suite() serve para que se possa adicionar todos os métodos de testes que a classe possui e que devem ser executados. Caso um método nao seja adicionado ao TestSuite neste método, ele não serpa executado.
Edite o código inicial do projeto (“Project> View Source”), adicionando a chamativa ao CppUnit após a compilar a aplicação. Exemplo projExemplo.cpp:

#include <vcl.h>
#pragma hdrstop

#include "ITestRunner.h"
#include "FirstTest.h"
//---------------------------------------------------------------------------
WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
try
{
ITestRunner runner;

runner.addTest(FirstTest::suite());

runner.run();

}
catch (Exception &exception)
{
Application->ShowException(&exception);
}
catch (...)
{
try
{
throw Exception("");
}
catch (Exception &exception)
{
Application->ShowException(&exception);
}
}
return 0;
}

Pressione F9. Uma ferramenta gráfica aparecerá e você terá como visualizar todos os testes escritos na classe FirstTest. Clique em run e divirta-se.
Obs: propositalmente neste tutorial eu inseri um teste que falhará, para que você possa ver o funcionamento da ferramenta…

=)

Edit Note: Pequena correção para ampliar o entendimento do documento

Publicado em Agile, Geral, Programming, TDD | 4 Comentários »

Impressões do último dojo 30/08

Publicado por Victor Hugo Germano em Sexta-feira, Agosto 31, 2007

Saudações a todos!

Vou tentar resumir o que foi o último dojo:

Primeiramente me deixou surpreso a quantidade de pessoas interessadas no encontro, vindas principalmente do Grupo de usuario Java SC que ajudou a divulgar o evento dessa vez… e qual não foi a minha surpresao quando percebi que as pessoas estavam atrás de uma palestra a respeito de testes de software… (?)
Talvez pela falta completa de eventos técnicos em nosso estado, ou talvez pela falta de informação nesse blog a respeito do intuito e da definição do que é o Coding Dojo. Vamos tentar mudar essa situação melhorando a descrição do site e trazendo mais informações a respeito de Teste de Software e TDD.

Assim como já foi comentado pelo Ivan num post anterior, fico impressionado com a maneira que as pessoas desenvolvem… code-and-fix? Programação orientada a heroísmos? Um misto de cowboy coding e o jogo do “faço de tudo para justificar o erro”? Programação orientada a gambiarra?
Tudo bem, sei muito bem que o povo do Quality Assurance tem muito pra dizer e provar que minha crítica acima não é válida (afinal, existem equipes de teste) . Mais continuemos.

Após uma introdução sobre o CodingDojoFloripa, partimos para o evento em si…
Nossa intenção como dojoFloripa desta vez foi mostra, para resolver o desafio, a utilização do DBUnit. Mas antes de tudo resolvemos passar um pouco sobre testes, já que algumas pessoas não conheciam o junit e a nossa maneira de fazer testes.

Infelizmente para alguns, tivemos que continuar o programa e explicar o funcionamento do DBUnit. Assim, a adesão das pessoas não foi das melhores, devido principalmente à quantidade de conceitos tratados no dojo, fazendo com que uma parte das pessoas deixasse o certi (e ainda não sabemos com qual impressão).

Bem, mesmo assim acredito que o evento tenha sido um sucesso! Melhor ainda foi a discussão sobre quem iria ganhar a assinatura da MundoJava que sorteamos. Obviamente que fizemos os testes para isso! Grande Gustavo acabou levando (deveríamos ter feito mais testes até que meu nome aparecesse como vencedor…)

Melhor ainda foi a reunião de feedback. Alguns sugestões foram bastante pertinentes e que vamos acabar seguindo. Dentre elas:

- Indicação do nível de dificuldade e requisitos básicos para participar do dojo (mão serão restritivos, mas assumiremos que todos os presentes conhecem algo do assunto tratado)

- Apresentação sobre TDD e Testes que acabarei (juntamente com o Ivan e o Mueller) realizando, com a intenção de ampliar o número de eventos técnicos em florianópolis

- E vocês, o que acharam do evento?
É isso, o perfil auto-organizável do evento será SEMPRE mantido! Logo publicarei as fotos e o código fonte.

Obrigado a todos que participaram e obrigado ao apoio da Fundação CERTI!

Lembrando: inscrevam-se na lista para discutir a respeito

Publicado em Dojo, Programming, TDD | 2 Comentários »

Anti-Padrões de TDD

Publicado por Victor Hugo Germano em Quinta-feira, Agosto 23, 2007

Saudações! Sou Victor Hugo, do blog A Maldita Comédia , e vou ajudar o Ivan a atualizar este blog com informações relativas ao CodingDojo e a TDD. Então vamos lá!

Traduzi um texto do blog do James Carr que trata sobre Anti-padrões de TDD. Bastante interessante, mas ainda falta um pouco de discussão a respeito. Seguem abaixo os principais (e mais comuns) anti-padrões:

Veja a Lista Completa

  • The Liar
    • Todos os metodos de um teste unitário estão passando perfeitamente, aparentando serem validos, entretanto sob uma inspeção mais próxima é descoberto que o teste unitário não testa o real intuíto para que foi criado.
  • Excessive Setup
    • Um teste que necessita muito trabalho para ser configurado antes mesmo de ser executado. Algumas vezes centenas de linhas de código tornam-se necessárias para adaptar o ambiente a um único método de testes, com dezenas de objetos envolvidos. Aqui a maior dificuldade é compreender “o quê” realmente está sendo testado dentro de toda a “sujeira” que um setup pode causar. (tradutor: Lembrem-se sempre do princípio KISS)
  • The local Hero
    • Um teste que é dependente de algo específico do ambiente de desenvolvimento em que ele foi escrito. O resultado: o teste passa perfeitamente na células de desenvolvimento, mas falha quando alguém tenta executá-lo fora desse ambiente.
  • The Stranger
    • Um método de teste que nem ao menos pertence ao Teste Unitário que ele está inserido. O método está realmente testando um objeto separado e independente, normalmente um objeto utilizado pelo objeto que sofre o teste.

É isso ai… Veja a Lista Completa

Publicado em Agile, Programming, TDD | 3 Comentários »

Próxima reunião do Coding Dojo Floripa

Publicado por Ivan Sanchez em Segunda-feira, Julho 23, 2007

Tentando seguir o ritmo de uma reunião por mês, a próxima já está marcada:

Data: 31 de Julho de 2007
Horário: das 19 as 22 hrs
Local: Fundação Certi (mapa)

A única diferença desta para a última reunião é que agora é preciso confirmar a presença via e-mail com o Gustavo, informando nome completo e CPF, para ter a entrada liberada no prédio da fundação. Se quiser saber mais sobre o provável desafio, dê uma olhada no blog do Rafael Mueller, ou inscreva-se na nossa lista de discussão. Além de TDD, a reunião promete também o uso de mocks e stubs, então vale a pena comparecer :)

Publicado em Dojo, Programming, TDD | 2 Comentários »

Screencast: TDD em Ação

Publicado por Ivan Sanchez em Segunda-feira, Maio 21, 2007

Conforme prometido, aqui está o screencast de um exemplo real de TDD. O vídeo tem aproximadamente 14 minutos (expremidos heroicamente em menos de 8MB), e trata um pouco dos seguintes assuntos:

  • Organização dos testes no eclipse
  • O fluxo de trabalho do TDD (vermelho-verde)
  • Desenvolvimento incremental (baby steps)
  • Implementar a solução mais simples que funcione (Fake It)
  • Como refatorar com maior segurança graças aos testes
  • Criação de testes para tratamento de exceções

Tentei usar um exercício extremamente simples para poder me focar mais na maneira de se raciocinar usando TDD. Como este é meu primeiro screencast acredito que ele está longe da perfeição (o áudio teve que ser substituído por legendas, por exemplo), mas espero que seja útil mesmo assim :-)

Assista o screencast TDD em Ação

Publicado em Programming, TDD, eXtreme Programming | 9 Comentários »

Minicurso de TDD

Publicado por Ivan Sanchez em Sábado, Maio 19, 2007

Antes tarde do que nunca, estou disponibilizando os slides do Minicurso de TDD que ministrei no Sun Tech Days em Florianópolis. São apenas 10 slides, mas que podem ajudar pra quem está aprendendo ou pensando em apresentar alguma coisa sobre o tema.

O último slide propõe um exercício que foi resolvido na hora com ajuda da platéia. Já transformei a resolução dele num screencast e estou finalizando sua edição para postar aqui no blog também. Enquanto este não está pronto, você pode baixar os slides do minicurso.

Publicado em Programming, TDD | 3 Comentários »

Métrica simples e útil? Use RCT

Publicado por Ivan Sanchez em Sexta-feira, Maio 11, 2007

RCT, ou Relação Código-Teste (Code To Test Ratio) é uma métrica extremamente simples, que permite verificar como andam os testes durante o projeto:

RCT = Linhas de Teste / Linhas de Código

Normalmente o valor obtido varia entre 0, quando não existe nenhum teste, e 1,5, quando se escreve 50% de linhas de teste a mais do que linhas de código. Até hoje não vi muitos projetos passarem deste valor, mas já é bastante normal ver projetos nesta faixa. Veja alguns exemplos no Code to Test Ratio Showdown.

O interessante desta métrica é que ela pode servir para acompanhar a adoção de TDD e verificar se os testes não estão sendo deixados de lado. Por isso ela deve ser coletada periodicamente, e deve-se buscar um valor que varie muito pouco quando a utilização de testes estiver satisfatória.

Atualmente estou trabalhando num projeto onde a RCT é 1.3. Em projetos Ruby on Rails a RCT é facimente obtido via rake stats:

Code LOC: 549 Test LOC: 690 Code to Test Ratio: 1:1.3

O projeto ainda está no começo (pouco mais de 500 linhas de código), mas o meu objetivo é que minha RCT nunca baixe de 1.3, e se possível alcance 1.4 quando eu passar a fazer mais testes de integração :-)

E no seu projeto, quantas linhas de teste você gera para cada linha de código? Se você obter a RCT do seu projeto, divulgue-a nos comentários!

Publicado em Programming, TDD, eXtreme Programming | 3 Comentários »

TDD on Rails

Publicado por Ivan Sanchez em Sexta-feira, Maio 11, 2007

O Nando Vieira postou o primeiro do que parece ser uma série de posts sobre Test-Driven Development no Ruby On Rails.

O primeiro episódio trata dos testes de unidade e como testar os Models da aplicação.

Vale a pena conferir.

Publicado em Programming, TDD | Leave a Comment »

XP Checklist #2: Desenvolvimento Orientado a Testes

Publicado por Ivan Sanchez em Quarta-feira, Maio 9, 2007

Visão geral do Desenvolvimento Orientado a Testes:

Para extrair o máximo dos testes durante o desenvolvimento, devemos pensar neles como uma ferramenta de comunicação e aprendizado contínuo. Portanto seu foco deve ir além da verificação e pautar o desenvolvimento como um todo.

Objetivo:

Ajudar o desenvolvimento e aumentar a confiança para fazer qualquer modificação no sistema.

Participantes:

  • Cliente
  • Equipe de Desenvolvimento

Pontos principais:

  • Todos os testes devem ser automatizados.
  • Os testes são escritos antes mesmo da funcionalidade existir
  • Uma User Story está pronta quando todos os Testes de Aceitação passam e não se consegue imaginar mais testes para ela
  • O desenvolvimento é feito em pequenos incrementos (“baby steps”)
  • O projeto da implementação deve favorecer a confecção de testes
  • O Cliente escreve testes de aceitação com ajuda da Equipe de Desenvolvimento. Se isso não é possível é interessante que ele ao menos valide o testes que a Equipe de Desenvolvimento criar
  • A depuração de código deve ser substituída por testes sempre que possível
  • Busca-se que todos os testes passem sempre. Se algo não está funcionando isto deve ser do conhecimento do Cliente.
  • Um novo teste deve ser escrito quando for preciso reproduzir um erro ou esclarecer melhor uma funcionalidade.

Resultados esperados:

  • O cliente terá maior confiança que as User Stories que ele definiu estão implementadas
  • A equipe terá maior confiança para fazer as mudanças que o cliente pedirá no futuro
  • Existirá sempre uma especificação atualizada, representada pelos testes
  • O design do software será favorecido pela simplicidade
  • A ocorrência de erros diminuirá

Atualização:
(11/05/2007) Novos itens foram adicionados nos Resultados Esperados (agradecimentos ao ViniciusAC)

Publicado em TDD, eXtreme Programming | 3 Comentários »