Segue a divulgação de um evento bacana em Gravataí-RS. Se trata de um evento beneficiente, então quem estiver na área j[a tem mais um bom motivo para comparecer…

Olá Pessoal,

Em janeiro, o Curso de Sistemas de Informação da FACENSA (Gravataí), juntamente com o Grupo de Usuários de Metodologias Ágeis (GUMA-RS) estará promovendo uma palestra beneficente sobre Metodologias Ágeis de Software. O assunto trata de um conjunto de metodologias de desenvolvimento de software que trabalham baseadas em um conjunto de princípios e valores, e baseadas em foco no cliente, na equipe e geração de resultados com métricas e atitudes que promovem a melhoria contínua.

Esta palestra vai trazer aos participantes uma introdução ao assunto, permitindo o debate e discussão dos tópicos tratados.

Data: 06 de janeiro de 2009, às 19h30min. A palestra tem duração de 3 horas.

Para esta ação, o Curso de Sistemas de Informação/FACENSA está arrecadando alimentos não perecíveis. A inscrição para a palestra é feita a partir da doação de 2Kg de alimentos. Os alimentos arrecadados serão doados para o Asilo Santa Bárbara (Gravataí).

Mais informações no blog do grupo XP – Rio Grande do SUL.

Há 6 meses atrás eu escrevi sobre a queda do movimento ágil, mas o James Shore foi bem mais esperto: ele decidiu cutucar na ferida do Scrum. E agora que a polêmica está no ar, muita gente na comunidade ágil brasileira resolveu se manifestar, dentre eles:

Phillip Calçado:

[...] What James describes in his text is what we, consultants, see every single day.

Rafael Mueller:

[...] Tá cheio de consultor por aí pronto para quebrar os valores ágeis somente para ganhar um dinheiro da sua empresa.

Victor Hugo Germano:

[...] São os princípios, e não os métodos, que decidirão sobre a sobrevivência dos projetos

José Papo

[...] Scrum é apenas a porta de entrada para a agilidade. Uma equipe que não evoluir além disso, com certeza irá fracassar.

Manoel Pimentel

[...] Não existe uma só forma de agilidade [...] Será que não há espaço para todas essas vertentes da agilidade?

Fernando Meyer

[...] não é trazendo um evangelista e adotanto Scrum para sua empresa que fará seus projetos darem certo, mas se e somente se as pessoas envolvidas acreditarem no que estão fazendo.

Frank Trindade:

[...] O problema acontece quando tudo isso se torna muito na moda e popular, o que leva um monte de gente a adotar metodologias ágeis sem ter muita noção do que está fazendo.

Guilherme Chapiewski:

[...] muitas pessoas na comunidade – assim como eu – têm receio que realmente estejamos entrando numa era de declínio das metodologias ágeis causada pelo seu mal uso e péssimo entendimento.

Minha opinião continua a mesma então não vou entrar na discussão. Ao invés disso vou tentar manter este post atualizado com outros posts que eu encontrar por aí. Estou curioso para saber o quanto esta discussão vai mudar a cara da comunidade brasileira

Atualizado! Mais algumas opiniões: Fernando Meyer, Frank Trindade e Guilherme Chapiewski (se souberem de mais alguém me avisem!)

Se você já tentou usar FitNesse alguma vez, é bem provável que você já desanimou com a documentação oficial. A boa notícia é que agora você pode consultar a Fixture Gallery, que é na verdade um livro de receitas bem completo e acessível.

Ah! E se você nunca usou FitNesse, talvez esteja na hora de dar uma olhada. Na pior das hipóteses é uma excelente ferramenta para escrever testes de maneira expressiva. No melhor caso, é uma ótima ferramenta de comunicação entre desenvolvedores, clientes e testers.

Quando o assunto é interface web, a maioria dos desenvolvedores sabe o quão complicado é escrever testes automatizados, e muita gente simplesmente acaba deixando de lado esse assunto na prática, talvez por não saber o tamanho da irresponsabilidade que isto significa. Como o Vínicius da ImproveIt já bem disse:

Desenvolver software sem testes não é apenas coisa de fanfarrão. É coisa de irresponsável. É impossível uma atividade tão complexa quanto desenvolver software ser conduzida sem testes automatizados, em uma quantidade absurda. Quer dizer, possível é, mas não é aceitável.

No caso específico de interfaces web, muitos usuários do Selenium já passaram pelo extremo da empolgação, quando em 5 minutos se instala a Selenium IDE no seu Firefox e sai gravando tudo que a sua aplicação pode fazer, e acabaram no desespero total quando a coleção de testes começa a aumentar e, mesmo depois de começar a usar o Selenium RC, manter os testes fica cada vez mais difícil a cada nova mudança. E o desenvolvimento guiado por testes por onde andou durante toda esta jornada? Provavelmente restrito a testes de unidade e integração, ou seja, sem tocar na interface com o usuário.

O engraçado é que a solução para tudo isso está bem mais perto do que a gente imagina: é a velha programação orientada a objetos, representada neste caso pelo padrão Page Objects (PO). A idéia é simples:

Representar os elementos da interface com o usuário como uma série de objetos que se comunicam entre si.

Se você prestou atenção, viu que este padrão está na documentação do WebDriver, uma outra ferramenta para automatizar interação com browsers, mas que para este post não tem muita importância, desde que você consiga conectar seus Page Objects com a aplicação real. Para provar isso, aqui vai um exemplo usando selenium-rc:

public class GoogleTest {

	private Selenium selenium;

	@Before
	public void setUp() throws Exception {
		selenium = new DefaultSelenium("localhost", 4444, "*firefox",
				"http://www.google.com/webhp?hl=en");
		selenium.start();
	}

	@Test
	public void codingDojoShouldBeInFirstPageOfResults() {
		GoogleHomePage home = new GoogleHomePage(selenium);
		GoogleSearchResults searchResults = home.searchFor("coding dojo");
		String firstEntry = searchResults.getResult(0);
		assertEquals("Coding Dojo Wiki: FrontPage", firstEntry);
	}

	@After
	public void tearDown() throws Exception {
		selenium.stop();
	}

}

Este exemplo usa dois POs bastante simples (GoogleHomePage e GoogleSearchResults):

public class GoogleHomePage {

	private final Selenium selenium;

	public GoogleHomePage(Selenium selenium) {
		this.selenium = selenium;
		this.selenium.open("http://www.google.com/webhp?hl=en");
		if (!"Google".equals(selenium.getTitle())) {
			throw new IllegalStateException("This is not the Google Home Page");
		}
	}

	public GoogleSearchResults searchFor(String string) {
		selenium.type("q", string);
		selenium.click("btnG");
		selenium.waitForPageToLoad("5000");
		return new GoogleSearchResults(string, selenium);
	}
}

public class GoogleSearchResults {

	private final Selenium selenium;

	public GoogleSearchResults(String string, Selenium selenium) {
		this.selenium = selenium;
		if (!(string + " - Google Search").equals(selenium.getTitle())) {
			throw new IllegalStateException(
					"This is not the Google Results Page");
		}
	}

	public String getResult(int i) {
		String nameXPath = "xpath=id('res')/div[1]/div[" + (i + 1) + "]/h2/a";
		return selenium.getText(nameXPath);
	}
}

Quais as vantagens desta abordagem?

É possível guiar seu desenvolvimento usando testes em cima de POs.

Imagine a interação do usuário com a aplicação e crie um modelo de objetos para representar essa interação. Verifique este modelo na forma de um novo teste. Enquanto os elementos da interface não existirem o teste vai falhar, então os crie baseando-se no modelo para fazer o seu teste passar. Escreva novos testes e faça-os passarem aos poucos, e nunca inclua algo na tela que não foi descrito na forma de testes.

É muito mais fácil manter classes do que scripts.

Não demorará muito para você começar a reutilizar seus POs e poder aplicar todos os recursos de refatoração que você já conhece. Novos testes poderão ser incluídos mais facilmente e mudanças no layout afetarão apenas POs específicos.

Então, ainda existe alguma razão para não escrever testes para a interface com o usuário? Espero que não, mas se tiver, me avise!

  There’s been some interesting commentary on the National Research Council of Canada’s paper titled “The Effectiveness of Test-first Approach to Programming” . The study, carried out on a sample size of 24 IT graduates, adds to the growing body of research on the topic. Though TDD is accepted as an excellent learning tool for quickly understanding the domain in which developers work, the question of whether TDD directly correlates quality in software is still considered unproven by some. This study, while still not conclusive, does show some interesting results – though different results, depending on who’s analysing them.

Leia post completo (InfoQ)

Saudações a todos!
A idéia surgiu no Chopp Dojo, partindo do pessoal da Fundação Certi (o Bosco).

Gostariamos de reunir as pessoas para conversarem e trocarem informações sobre metodologias de desenvolvimento/gerenciamento… nas palavras do próprio Bosco:

DOJO Metodologias: Dojo cujo objetivo é trocar experiência sobre
metodologias de desenvolvimento de software. Seria como se cada
participante fizesse uma pequena apresentação sobre a metodologia que
ele utiliza, SCRUM/XP e etc. Estas apresentações poderiam ser
informais e focadas na prática.

A reunião será realizada novamente na Fundação Certi às 19:00hs, e como todos os outros eventos por lá, é necessário confirmar presença:

Gustavo Maestri <gaa at certi.org.br>, enviando RG e nome completo.

Gostaria muito de ver pessoas relacionadas às áreas do MPS.BR ou RUP, OPEN UP, CMMI…

Saudações!
Seguindo uma série de posts iniciados pelo Rafael Mueller e apoiado pela Maldita Comédia, trago ao dojo a seguinte afirmação: Você acha que conhece javaScript, mas não tem a menor idéia.

JavaScript possui Orientação Objetos? – Sim!
JavaScript possui Testes? Claro que sim!
Aos mais acostumados com o JMock, o código abaixo não será muito problema:

var mockControl = new MockControl();
workerMock = mockControl.createMock(Worker);

workerMock.expects().isFinished().andReturn(true);
workerMock.expects().getValue().andReturn(‘hello’);

var result = doWork(workerMock);

assertEquals(‘hello’, result);
mockControl.verify();

Explicação rápida: Exemplo de utilização de um mock para determinar o comportamento da classe Worker ao ser executado o método doWork(). Simples… e se eu disser que esse código é javaScript? Legal né?

Encontrei duas ferramentas interessantes para auxiliar na construção de código em JavaScript: jsUnit e jsMock. Frameworks muito interessantes que não deixam a desejar em nenhum quesito relacionado a TDD. O exemplos existentes nos sites são bastante explicativos, não será um problema iniciar a criação de testes com as ferramentas. Sendo javascript uma linguagem pouco tipada, a técnica Stub é facilmente incorporada. Vale a pena tentar!

Falei grego? Ainda não sabe qual a diferença entre Mock & Stubs? Descubra aqui: Tudo sobre TDD

Votem em nossa enquete: O que o DojoFloripa pode fazer por você?

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!

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:

• CppUnit Wiki (inglês)
• Code Gear from Borland: CppUnit Tests with C++BuilderX (inglês)
  • nao funcionou corretamente no BSC6
• Curso online: Pruebas unitarias con CppUnit (espanhol)
  • funcionou corretamente no BSC6

Requisitos:

• Borland C++ Builder 6 =)
• Versão do CppUnit para o BCB6

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

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