Coding Dojo Floripa

Desenvolvimento Ágil

Arquivos para a Categoria ‘Programming’

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 »

Abrace as mudanças no seu software

Publicado por Ivan Sanchez em Segunda-feira, Abril 9, 2007

Um dos maiores fatores de estress em projetos de software é a mudança desordenada no escopo. As funcionalidades mudam durante o projeto com mais frequencia do que a equipe gostaria, e isso se reflete negativamente por todos os lados.

A questão é que a maioria das pessoas que já se envolveram com projetos de software sabem que as mudanças fazem parte (e a minoria se engana achando que não), porém dificilmente as pessoas se preparam para quando isso acontece. E os resultados mais comuns disso são: cliente insatisfeito, desenvolvolvedores frustrados e prazos/custos estourados. Isso sem mencionar a qualidade do produto final.

Por isso proponho 2 tarefas para melhorar este cenário:

  • Defina datas para as mudanças acontecerem

Duas coisas que incomodam os desenvolvedores são: interrupções e trabalho jogado fora. Uma maneira fácil de evitar isso é educar o cliente* para que faça seus pedidos apenas em datas pré-definidas. Obviamente o cliente vai continuar pedindo alterações a qualquer momento, mas é preciso deixar claro quando que estas alterações serão trabalhadas e o qual será o impacto delas.

Se o cliente começar a ficar insatisfeito com o quanto ele precisa esperar para ter suas mudanças, é sinal que estas datas precisam estar mais próximas uma das outras.

  • Automatize seus testes

Agora é a vez dos desenvolvedores fazerem a sua parte. Uma vez que as mudanças do cliente já são esperadas, é preciso fazer com que estas mudanças no software não signifiquem queda na qualidade. E é aí que entram os testes automatizados. Poder verificar facilmente todas as funcionalidades do sistema a qualquer momento é o que dá confiança para um desenvolvedor mudar qualquer coisa a qualquer momento.

O impacto de uma mudança de requisito pode ser maior ou menor, e os testes permitem verificar com mais clareza como a mudança se reflete no resto do sistema. Isto acontece porque uma vez que uma parte do software é modificada e todos os testes são executados, todos os pontos onde esta mudança causou problema são descobertos na hora. E com este feedback rápido os desenvolvedores poderão verificar se suas estimativas estavam corretas e se a implementação está correndo como o planejado.

Em resumo

Permitir que mudanças de escopo sejam bem-vindas num projeto de sofware precisa ser um esforço tanto de cliente quanto desenvolvedores e a palavra-chave para diminuir o estress é disciplina. Quanto mais previsíveis forem os clientes e mais testes automatizados forem escritos, melhor serão aceitas as mudanças.

* Definição de cliente: aquele que define os requisitos do software, não necessariamente aquele que está pagando.

Publicado em Agile, Programming | Leave a Comment »

XP Checklist #1: Jogo do Planejamento

Publicado por Ivan Sanchez em Terça-feira, Março 27, 2007

Visão Geral do Jogo do Planejamento:

É preciso conhecer o problema, levantar os requisitos, estimar o esforço e definir as entregas. A colaboração tanto da Equipe de Desenvolvimento quanto do Cliente é fundamental nesta etapa que será o ponto de partida para um novo ciclo de desenvolvimento.

Objetivo:

Definir os requisitos (User Stories) de maior valor, que deverão ser entregues no final da Iteração ou Release.

Participantes:

  • Cliente
  • Equipe de Desenvolvimento
  • Coach

Pontos principais:

  • Um objetivo concreto deve ser definido para a próxima Iteração/Release
  • A próxima Iteração/Release deve compreender o que há de mais valioso para o Cliente
  • Os requisitos devem ser representados em User Stories utilizando a linguagem do Cliente
  • O Cliente deve ter a chance de adicionar ou remover User Stories
  • As User Stories devem ser compreendidas pela Equipe de Deenvolvimento
  • A Equipe de Desenvolvimento pode quebrar ou unir User Stories com ajuda do Cliente
  • Um Glossário pode ser mantido para guardar o significado dos termos mais relevantes
  • No Planejamento da Iteração é desejável que as User Stories sejam quebradas em Tarefas técnicas pela Equipe de Desenvolvimento
  • O Cliente deve priorizar as User Stories
  • A Equipe de Desenvolvimento deve estimar cada User Story/Tarefa
  • Equipe de Desenvolvimento e Cliente discutem o que pode ser implementado na próxima Iteração/Release
  • A velocidade da equipe deve ser atualizada com base na última Iteração/Release:
    • Velocidade = (Total de Pontos) / Iteração ou Release

Resultados esperados:

  • O Cliente estará comprometido a disponibilizar mais informações sempre que necessário
  • O Cliente estará comprometido a dar seu feedback durante o desenvolvimento
  • A Equipe de Desenvolvimento estará comprometida a entregar o que há de mais valor para o Cliente ao final da Iteração/Release
  • A velocidade da Equipe de Desenvolvimento será conhecida

Publicado em Agile, Programming, eXtreme Programming | 2 Comentários »