Testes devem começar dessa forma:

Primeiro, Deus criou o céu e a terra…
E Deus disse, “Haja luz”…

E devem terminar da seguinte:

a besta que viste, era e não é, está para emergir do abismo e caminha para a destruição

Quando você começa a escrever o teste, não deve existir nenhuma dependência com o estado de um teste anterior. Se você vai usar o banco, ele deve estar vazio. Se vai usar uma classe que guarda estado em um campo static (ugh!), precisa (além de refatorar esse código), reiniciá-la.

Tem uma razão para que isso seja feito. Cada teste deve se comportar como um experimento que sempre dará o mesmo resultado (desde que você não mude o código) não importa quantas vezes você o rode.

Porque você quer isso? Para que não aconteçam falsos negativos e nem falsos positivos. Seus testes precisam ser confiáveis ou você vai passar a ignorá-los.

Imaginem o seguinte caso:

public void testaQueSalvaOsDados(){
	//Código que salva "bobagem"

	String dado = //código que recupera "bobagem";
	assertEquals("bobagem", dado);
}

public void testaQueListaDados(){
	List<String> dados = //código que busca todos os dados;

	assertEquals(1, dados.size());
	assertEquals("bobagem", dados.get(0));
}

Se você rodasse esses testes, o segundo teste passaria apenas na primeira vez. Após isso, ele iria falhar no primeiro assert (o do tamanho da lista).

Esse é um caso bem óbvio de utilização de efeitos colaterais de outro teste. E pode acontecer coisa pior. Imagine que depois de rodar os testes a primeira vez, você quebra o “código que busca todos os dados” e ele passa a trazer apenas o primeiro encontrado. Você terá um bug muito difícil de encontrar, porque os testes passam.

Novamente, esse é um caso bem óbvio. Interações bem mais sutis que essas podem acontecer e você vai sofrer muito para encontrar.

Por isso, sempre que seu teste causar algum efeito colateral, desfaça esse efeito. A sanidade dos programadores que vão dar manutenção no seu código agradece.

Se quiser aprender mais sobre testes, dê uma olhada em nosso treinamento Scrum Developer Skills.

Enquanto eu resolvia o primeiro desafio de expressividade que postei no VidaGeek.net, me deparei com uma situação comum para programadores Java.

Eu precisava que a classe java.lang.String fosse capaz de fazer coisas (como inverter a string) que ela não é.

A solução mais comum seria criar uma classe Strings (seguindo o padrão da java.util.Collections) que conteria o comportamento.

Daí para usá-la, seria da seguinte forma:

Strings.inverte(suaString);

O problema é que isso espalha o comportamento que deveria pertencer à String (que não temos como alterar).

Ao invéz de solucionar o problema dessa forma, resolvi usar um Tiny Type para encapsular essa string (chamei de BinaryString).

Essa BinaryString é capaz de se inverter, além de eu poder dar os nomes que eu quiser para os métodos (deixando mais expressivo).

Mas a maior vantagem de ter usado esse Tiny Type é que ele me abriu possibilidades que não existiam no código sem ele e eu mudei completamente a solução que pretendia criar. A nova solução ficou (na minha opnião) mais elegante e expressiva.

Se tiverem maior interesse sobre Tiny Types, eu escrevi sobre o assunto aqui e tem um post do Darren Hobbs que é onde eu entrei em contato com o assunto.

Além disso, no nosso novo treinamento Scrum Developer Skills, vários assuntos relacionados à expressividade são abordados, incluindo Tiny Types.

Nesta última terça-feira, 12 de Abril, tivemos mais um Codigo Dojo na AdaptWorks. Claro, a chuva que caiu no final da tarde atrapalhou um pouco, mas mesmo assim tivemos uma boa quantidade de participantes.

Desta vez resolvemos mudar o condutor do Dojo e o escolhido foi o Juliano Alves (obrigado, Juliano).

Jonas e Juliano, apresentando as opções para o problema

Apesar de algumas pessoas reclamarem, parece que Java continua sendo o “common ground” para a maioria dos participantes. Não que seja um problema, mas alguns gostariam de uma pequena mudança, conhecer uma outra linguagem.

Platéia atenta, mas participativa

Algumas pessoas talvez se sintam constrangidas em participar de um Coding Dojo – algumas por não se acharem com conhecimento suficiente ou por acharem que isso é para um nível mais alto de programação. E para estas situações, é importante lembrar que um Coding Dojo não é criado para mensurar o seu “traquejo” na linguagem, e sim mostrar (e usar) boas práticas em programação.

"Pair Programming", uma das práticas mais usadas

Inclusive, na Retrospectiva feita ao final da sessão, um dos comentários positivos foi a diferença positiva sentida quando praticando “pair programming”. E é por aí que as coisas se encaminham.

Graças a colaboração e boa vontade do Guiseppe Proment da Fujitsu, ontem realizamos uma nova sessão de Coding Dojo em Smalltalk e utilizamos o Pharo pra suíte de testes. Poucos participantes conheciam Smalltalk e só o Guiseppe tinha experiência com o Pharo, o que tornou a sessão ainda mais interessante. No começo a maioria sentiu-se fora da sua zona de conforto, mas na retrospectiva todos chegaram a conclusão de que essa sensação era muito positiva.

No dojo anterior a esse (desculpem por não divulgarmos) contamos com a ajuda do Diogo Baeder que coordenou muito bem a sessão de Dojo em Javascript e o uso do QUnit que era desconhecido pela maioria dos participantes.

Esse tipo de apoio dos participantes tem ajudando em muito, tornando as sessões ainda mais atrativas e evitando que percam interesse no Dojo e que ele acabe “morrendo”.

Veja todas as fotos do Dojo

Participe da nossa lista de discussão

Ontem (27/07) organizamos outra sessão de Coding Dojo aqui na AdaptWorks, especialmente dessa vez contamos com novos participantes da Gonow e da Fujitsu, que enriqueceram muito o Dojo.

Agradeço a participação e paciência de todos.

Veja todas as fotos do Dojo

Realizamos outra sessão de Coding Dojo no dia 18/05 aqui na AdaptWorks. Dessa vez além de ter fluído melhor, conseguimos organizar melhor o Dojo e os participantes por sua vez estão mais colaborativos e cada vez mais disciplinados.

Veja todas as fotos do Dojo

Ontem realizamos o primeiro Coding Dojo aqui na AdaptWorks. Foi uma ótima experiência tanto para os participantes quanto para a AdaptWorks, pois foi o primeiro evento que organizamos na nova sede.

Na retrospectiva encontramos vários pontos que devemos melhorar para os próximos dojos, mas mesmo assim foi muito divertido, o que nos incentiva a repertimos a dose.

Veja todas as fotos do Dojo

Tempos atrás me encontrei em uma situação interessante. Por problemas de comunicação, eu estava em um lugar e deveria estar em outro. Quem já não passou por isso?

Mas o que me chamou a atenção foi a primeira pergunta que me foi feita quando notamos o problema. “Quem falou para você vir para cá?”. Por reflexo respondi, mas fiquei com isso na cabeça.

O que eu vi acontecer nos próximos minutos foi uma rápida caça às bruxas. O importante não era descobrir como eu chegaria a tempo no local certo e sim descobrir quem era o culpado por eu estar no lugar errado. Não tem algo de estranho por aqui? O que seria ganho encontrando o culpado?

Isso é um traço cultural de muitas empresas. Essa “cultura do culpado” é muito forte e costuma trazer efeitos desastrosos. O erro passa a ser tratado como a pior coisa que pode acontecer e não como parte do aprendizado. Como o erro é uma ofensa terrível, ele deve ser escondido. Pronto. Acabamos de destruir uma empresa. Esses erros que ficam ocultos vão minando as bases da empresa até o ponto em que ela fica insustentável.

Uma solução a essa “cultura do culpado” é uma “cultura da solução”. O culpado passa a ser um personagem secundário. O realmente importante é encontrar uma solução e voltar o mais rápido possível ao estado normal de trabalho. Essa forma de agir tem algumas vantagens:

• Seus problemas são solucionados mais rápido
• O erro passa a ser parte do aprendizado e por isso não faz sentido ter medo e escondê-los
• Como seus erros estão visíveis, você finalmente tem a chance de fazer melhorias reais para evitar que eles aconteçam novamente

Essa “cultura da solução” é um dos principais pontos dentro de Scrum (e também é uma das mais difíceis de serem implantadas). Toda a parte de Inspecionar e Adaptar só é possível se você tiver (não apenas dentro do time, mas com todos os envolvidos no projeto) segurança para relatar os problemas que tem acontecido.

Recentemente, acompanhando a lista de discussão sobre Scrum “Scrum Development”, vi uma discussão interessante sobre um programador que afirmava precisar de tempo de isolamento para trabalhar.

Isso me fez pensar bastante. Realmente várias vezes eu senti necessidade de me isolar para poder trabalhar (em especial em um momento me que eu precisava implementar algum algoritmo específico ou precisava otimizar determinado código). Isso fez muito sentido na minha cabeça e durante um tempo cheguei a concordar com o programador. Mas será que isso é uma coisa boa?

Vamos analisar a curto prazo. Durante duas horas eu me isolo da equipe (não posso mais chamar de time pois estou trabalhando sozinho) e resolvo o problema. Foi vantajoso porque se eu parasse para discutir ou utilizasse pair-programming demoraria cerca de 8 horas (algoritmos são bem difíceis de explicar para quem ainda não teve contato com ele). Aumentei a velocidade do time e isso foi uma coisa boa, correto?

Não. Essa foi a pior atitude que poderia ser tomada. Pensem na sequinte situação ocorrendo logo após essa.

Novamente a equipe é confrontada com um problema semelhante. Quem é o único que tem experiência resolvendo esse tipo de problema? Eu. Então novamente me isolo da equipe para resolvê-lo. Começaram a notar onde pretendo chegar?

No momento em que me isolei da equipe, eu causei um dano muito sério. Retive conhecimento ao invéz de compartilha-lo. Se apenas eu sei como lidar com o problema, na próxima vez que ele ocorrer ou quando for necessário dar manutenção, eu preciso trabalhar nele. Ou seja, o Truck Factor para aquele trecho de código é 1.

Porque isso é muito ruim? Um programador com tendência de concentrar informação, não vai concentrar apenas um dos pontos. Ele irá agir dessa forma muitas outras vezes. Logo, ele será o único com conhecimento para resolver muitos problemas, causando um sério impedimento. Isso sem contar que a equipe não vai ter a oportunidade de crescer e aprender a resolver esse problema.

Isso é uma atitude de muita irresponsabilidade. O crescimento da equipe deve ser prioridade para todos os programadores da equipe. Apenas agindo dessa forma a equipe poderá passar a ser um time.

Acredito que em todos os projetos nos quais já trabalhei, documentação foi um fator determinante para o sucesso ou fracasso do projeto. Documentação é muito importante e chega a ser irresponsável dizer que documentação é inútil.

Na minha opnião, documentação é uma forma de comunicação entre você (programador/documentador do presente) e você ou outros (programadores/gerentes do futuro – sendo futuro qualquer momento posterior à escrita da documentação). Através da documentação, tem que ser explicado para o próximo o que aquele sistema ou módulo faz. Essa é a função primordial da documentação.

Mas documentação não é apenas escrever dezenas de UMLs. Como disse, documentação é uma forma de comunicação e por definição não pode estar restrita à modelos. Modelos são ótimos para termos um lugar de onde partir (afinal, a melhor forma de aprendizado é através da cópia), mas temos que ter consciência de que devemos criar nossas próprias formas de comunicação com nossa equipe futura.

O que muitos acreditam erroneamente é que agilistas não gostam de documentação. Isso com certeza não é verdade. A maioria dos agilistas que vejo é mais preocupada com documentação do que desenvolvedores que utilizam processos tradicionais. A grande diferença é como cada um lida com a documentação.

Em um processo tradicional, a documentação é vista como uma obrigação. E obrigações são chatas e entediantes, não importa qual seja. Os agilistas encaram de outra forma. A documentação é uma responsabilidade de toda a equipe.

Então você não pode ter alguém responsável por escrever a documentação em uma equipe? Claro que pode (e talvez deva). Mas o ponto de ser uma responsabilidade afeta todos os tipos de documentação, não apenas os que devem ser entregues a algum gerente/supervisor/chefe.

Uma documentação que costuma ser muito ignorada é o próprio código. Como documentação é uma forma de comunicação entre o agora e o futuro, o código fonte da aplicação é o primeiro ponto de contato. Código auto-documentado é um dos principais tipos de documentação. Nenhum outro é capaz de suprir sua falta, porque esse é o código que realmente roda em produção (e consequentemente é quem traz dinheiro para a empresa). E notem a ênfase em auto. Eu não estou falando em ferramentas como javadoc, ndoc, ou comentários. Estou falando sobre código que além de legível é compreensível. Existe uma grande diferença entre os dois. Na comunidade de desenvolvimento SmallTalk isso é levado muito a sério. As boas práticas dizem que se você sentir a necessidade de acrescentar um comentário, você deve alterar o código para que fique mais compreensível e o comentário seja desnecessário.

Um segundo ponto de contato muito importante são os testes automatizados. Testes nada mais são do que documentação funcional do seu código, que ainda tem uma vantagem sobre os outros tipos. Eles são capazes de dizer se o seu código está certo com relação à quando o teste foi escrito. Se um teste falha, significa que o código está errado ou que o teste perdeu o sentido (ou seja, você nunca corre o risco de ficar com essa documentação desatualizada).

Esses são dois tipos de documentação que tem manutenção automática. Você não precisa lembrar de alterar o documento DOC4129-X porque acrescentou um método à classe Funcionario. Acrescentando o método (e o teste), a documentação estará feita.

Mas isso é suficiente? Nem sempre. Trabalhei com vários projetos onde foi o suficiente. Vários outros, não chegou perto do mínimo necessário. Quando estou desenvolvendo uma API para uso público, eu costumo documentar (com uma ferramenta como javadoc) toda a parte pública dela (por mais que muitas vezes eu gaste mais tempo com a documentação do que escrevendo essa parte pública), porque preciso explicar tudo o que vai acontecer, sem que o usuário precise olhar a implementação. Se quero que o projeto ganhe visão, preciso de uma documentação para o usuário, ensinando-o a usar o sistema (essa costuma levar mais tempo ainda).

O mais importante é lembrar que qualquer tipo de documentação exige esforço. Quanto desse esforço é convertido em valor para o projeto? O Toyota Production System é completamente baseado em eliminação de desperdício. E desperdício é qualquer coisa que não acrescente valor ao produto ou cliente. Quanto da documentação nos seus projetos atuais agregam valor aos seus clientes? Todas as 10 páginas para se criar uma modificação em uma classe? Então essa documentação é ótima. Nenhum dos diagramas UML? Então essa documentação precisa ser reavaliada.

Documentação é tão vital quanto água. Sem documentação, um projeto pode morrer. Com documentação excessiva, também.