Finalmente está no ar a versão pt_BR da FIT/FitNesse Fixture Galery. Ela está disponíveis em três versões:

• Versão em PDF para imprimir
• Um wiki FitNesse executável
• Um wiki on-line

E é bem simples, por sinal:

A melhor maneira de acelerar Selenium é usar menos Selenium

Ou seja: use mais testes de unidade, mais testes de integração e dependa menos dos testes a partir da interface com o usuário. Use Selenium apenas para validar a navegação, mas não regras de negócios. E, finalmente, use Page Objects, porque pior do que testes difíceis de se executar são testes difíceis de se manter.

Nas últimas semanas tenho matado minha saudade dos Coding Dojos!

Primeiro conheci no Google Open Source Jam o pessoal de uma empresa que está fazendo dojos internos e me convidaram para participar. E não é que foi um dos melhores dojos que já participei até hoje? Organizar dojos dentro de uma empresa tem várias peculiaridades, mas isso é assunto para outro post…

Na semana seguinte aconteceu o primeiro dojo na empresa onde eu trabalho. Infelizmente minha organização foi precária e não pude avisar com antecedência o suficiente para o Danilo Sato do Dojo SP poder participar, porém acabamos contando com a visita de um outro programador de fora. Foi bem divertido também e agora estamos tentando tornar o dojo algo mais rotineiro.

Enfim, depois de quase 7 meses sem participar de reuniões do dojo, finalmente estou voltando à ativa!

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!

Saudações a todos!

Bem, ontem tivemos nossa primeira sessão do ano….
Contando com a presença de  nove participantes, dentre eles  5 novos visitantes, resolvemos um tema bastante interessante, mesmo que meio improvisado: código legado

Existia um projeto perdido criado nas próprias edições do dojo, tentando resolver nosso primeiro desafio – sim, akele do poker – . O passo foi o seguinte: evoluir akela implementação…
Muito bom saber que todas as pessoas já haviam ao menos visto JUnit, e passamos rapidamente para a elucidação dos problemas.
Ponto bastante importante para mim: perceber a ajuda que um bando de testes pode fazer num momento desses. Veja a situação: 9 pessoas querendo mexer num código que foi feito há quase um ano … obviamente sem documentação, com uma noção não muito boa das regras do jogo de poker (apenas 3 jah conheciam o desafio e o jogo de verdade)… o que aconteceria se não tivessemos uns 40 testes para nos ajudar??? Seria péssimo, com toda certeza… foi bom voltar a programar (o meu dedilhado não está dos melhores…)

Experiência bastante interessante, não pela programação em si, mas por perceber que ainda existem pessoas interessadas a escrever software de forma profissional.

Sobre a retrospectiva da sessão:

• Precisamos nos organizar mais
• Melhor seria através não de jogos, mas de situações mais “reais” (?!)
• Poderíamos evoluir o próprio jogo de poker e atender a uma séria de demandas: redes, IA, multithreading, etc…
• Cade um SVN pro dojo!?!?!?!?!?!?
• Reuniões poderiam ser ao menos quinzenais

E foi dado o primeiro passo!!

Senhores, apresento a você o Assembla,  um ambiente que permite criar um projeto integrando ferramentas de ticket, wiki e controle de versões. E o que eu fiz? Criei um repositório/projeto para o CodingDojo!! Isso mesmo, assim, acredito que será possível utilizar e evoluir este mesmo projeto do DojoPoker para mais do que apenas exemplos fracos de programação…

Vejam o código produzido na última reunião:

SVN ACCESS: http://svn2.assembla.com/svn/dojofloripa (disponível publicamente para baixar)

É isso…  aguardaremos o desenrolar dessas histórias

Victor @ A Maldita Comédia

A nossa próxima reunião já está marcada…

Data: 20/02 – Quarta-feira, as 19 hrs
Local: Fundação Certi

A idéia é apresentar um desafio envolvendo multithreading. Se você quiser participar da escolha do problema ainda dá tempo.

Para participar da reunião você só precisa confirmar sua presença.

  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)

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!
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!
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?

• Wikipedia (inglês)
• Scott Ambler(inglês)
• Introdução ao TDD: fazer os testes passarem deve ser a única preocupação agora (português)
• Confusões sobre TDD (português)

Miscelânia:

• Abrace as mudanças em seu software (português)
• Top 5 desculpas para não programar orientado a testes (português)
• TDD vs UML (português)

Videos:

• Tipos de Teste: palestra AgilCoop (português)
• Agile Testing (português/inglês)

TDD na prática:

• Screencast: TDD em Ação (português)
• TDD parte 1: por onde começar (portugês)
• TDD parte 2: Baby Steps e Tratamento de Exceções: (português)
• TDD parte 3: Corrigindo bugs (português)
• CppUnit e Borland C++ Builder6: (português)

Técnicas:

• Fake it (português)
• Trabalhando com stubs: (português)
• Mocks & Stubs, qual a diferença afinal? (português)
• TDD Anti-Patterns (português)

Livros:

• Test Driven Development: A pratical Guide 
•  Refactoring: Improving the design of existingcode
• Test Driven Development by Example 
• Automação e Gerenciamento de Testes: Aumentando a Produtividade com as Principais Soluções OpenSource e Grauitas (ebook)

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!