Japybara – testes funcionais e de integração para java

Faz muito tempo que tenho uma preocupação muito grande com testes automatizados.

Meu primeiro contato foi, obviamente, com o JUnit, ainda em 2001. O que mais me encantou foi a possibilidade de aniquilar um fantasma que assusta muita gente: o “eu juro que já tinha testado!”.

Quantas vezes não fiquei com carão ao ver um bug que, sim, eu já tinha corrigido, mas ele teimava em voltar. Ou ainda mais simples: um bug desconhecido (e óbvio) sobre uma funcionalidade que já tinha sido bem testada, mas que quebrou por um efeito colateral qualquer.

Assim, a primeira coisa que me pegou foi a possibilidade de ter testes de regressão. Mas, obviamente, não foi a única. Junto com isso veio outras coisas, como o TDD, suporte a refactoring de gente grande, segurança, explorações, etc.

TDD and Uncle Bob in 3 blog posts

Echoes from the Stone Age

Anyone who continues to think that TDD slows you down is living in the stone age. Sorry, that’s just the truth. TDD does not slow you down, it speeds you up.
…
I completely and utterly reject the notion that ignorance is the best defense. I reject that lack of skill can ever be an advantage.
…

Em TDD Derangement Syndrome, a parte mais interessante é quando ele aponta algumas pesquisas feitas sobre TDD:

We found that test-first students on average wrote more tests and, in turn, students who wrote more tests tended to be more productive. We also observed that the minimum quality increased linearly with the number of programmer tests, independent of the development strategy employed.
…
* 87.5% of developers reported better requirements understanding.
* 95.8% of developers reported reduced debugging efforts.
* 78% of developers reported TDD improved overall productivity.
* 50% of developers found that it decreased overall development time.
* 92% of developers felt that TDD yielded high-quality code.
* 79% of developers believed TDD promoted simpler design.

Em TDD Triage, ele estrutura o artigo na forma de questões:

• Is TDD a replacement for architecture?
• Is TDD a replacement for design?
• Should TDD be used for every line of code?
• Well, if you are going to write some tests afterwards, why not write all tests afterwards?
• Given that we accept the need for tests, why the resistance to test-first?
• Wouldn’t it be faster without such high test coverage?

Mais: “TDD does not slow you down, it speeds you up”

Verdade, e isto deve ser sempre buscado. Se você pede mais tempo para escrever os testes, verifique se você está usando as técnicas direito, pois o oposto deveria ocorrer: você terminou seu trabalho mais cedo porque usou TDD. E lembrando que terminar é deixar o negócio funcionando direito, e não de qualquer jeito! Ou como ironiza o Kent Beck: “If it doesn’t have to work, I can get it done a lot faster!”

Só de não ter que ficar fazendo deploy e entrando com dados num navegador… putz! Ajuda demais! Fora respostas rápidas para o “será que eu quebrei algo?”

Mas verifique o contexto: não é sempre que TDD ou mesmo testes automatizados se aplicam bem. Ou, pelo menos, selecione cuidadosamente quais técnicas são apropriadas para cada situação. Avaliar isso é difícil antes e fácil depois: ajudou ou não?

Scaling Lucene and Solr

While many Lucene/Solr applications will never outgrow a single, well-configured machine, the fact is, more and more applications are pushing beyond the single machine limit due to either index size or query volume. In discussing Lucene and Solr best practices for performance and scaling, Mark Miller explains how to get the most out of a single machine, as well as how to scale out to harness multiple machines to handle large indexes, large query volume, or both.

Scaling Lucene and Solr

Nielsen Norman Group Report: Agile Usability: Best Practices for User Experience on Agile Development Projects

Jakob Nielsen, um dos marketeiros papas da usabilidade, fez um estudo sobre este assunto (UX) em um ambiente ágil.

Rapid Application Development (RAD) processes such as Agile, Scrum, and the like, simultaneously pose an opportunity and a threat to achieving a quality user experience. It all depends on how it’s handled. The standard methodologies as described in books don’t work in practice, if you care about the usability of your products. But small modifications work wonders, as we found when studying how Agile works on real projects.

The report contains detailed analyses of five trends we saw in most successful organizations:

• UX people are bridges: embedded with the team but also involved in high level/early planning
• UX work is early, flexible: done up-front to storyboard level with good expectation setting that changes will happen
• Low-fi prototype is the ongoing spec: owned by UX, agreed by stakeholders
• UX work happens in a parallel track: pair complex back-end sprints with UX intensive work
• Guerilla style UX validation: fast, discount methods run frequently and regularly on early code

The report is based on case studies from 12 organizations that have embraced Agile while also caring about user experience. Further adding to the empirical evidence in the report are the findings from surveying 105 professionals.

O sumário é interessante: