Arquivo da tag: tdd

Desenvolvimento de software não é construção civil

Ao longo dos últimos anos, uma das áreas que mais cresceu foi justamente a de tecnologia voltada para o desenvolvimento de software e, com esse grande impulso, vieram junto enormes problemas que vão desde qualidade, prazos e, principalmente, expectativas de todos os envolvidos no processo, levando grande parte dos projetos a algum tipo de fracasso, conforme podemos observar nos principais estudos relacionados, como o “Chaos report”, promovido pelo The Standish Group.

A arte de desenvolver software é baseada em um modelo completamente criativo e dinâmico, sujeito a mudanças em cada passo, sejam oriundas de uma amplificação no entendimento do valor de negócio por parte do cliente ou em atividades emergentes que surgem logo nos primeiros minutos de codificação em qualquer projeto de desenvolvimento de software.

As disciplinas tradicionais de gestão baseiam-se em muitas ideias aplicadas na própria construção civil e tentam, usando esses princípios, determinar os mesmos fundamentos para projetos de desenvolvimento de software desconsiderando que são modelos completamente diferentes e conduzidos por pessoas criativas. Eu costumo dizer que, ao projetar um prédio nós costumamos ver a evolução da construção, desde a fundação e paredes que vão aparecendo aos nossos olhos. Rapidamente você consegue pegar e medir quanto é necessário de investimento e esforço para atingir o objetivo. Já no software a realidade é completamente diferente, pois é emergente e adaptável em cada passo dado.

É hora de mudar e adotar atitudes mais ágeis que provoquem a colaboração e comprometimento entre todos os envolvidos no ciclo produtivo do software. Estamos falando de pessoas altamente criativas e não de máquinas ou “recursos”.

Em meados de 2001 os principais pensadores da época deram um grande passo reunindo-se para formação do “Manifesto para Desenvolvimento Ágil de Software” que representou um grande marco de mudança contra os modelos tradicionais de desenvolvimento de software com 4 pilares importantes:

  1. Indivíduos e interações mais que processos e ferramentas
  2. Software em funcionamento mais que documentação abrangente
  3. Colaboração com o cliente mais que negociação de contratos
  4. Responder a mudanças mais que seguir um plano

A base principal disso tudo são pessoas felizes colaborando com o processo produtivo que requer adaptação frequente e muita atenção para atender a expectativa do cliente dentro dos objetivos do projeto. No modelo ágil, direcionamos todas as energias em criar um software funcionando orientado aos desejos do cliente que, sabemos, nunca são iguais aos pensamentos originais. Eles emergem e amadurecem junto com as entregas frequentes de software que são apresentadas em cada final de Sprint.

Ao questionar diversos desenvolvedores sobre documentação de software durante a manutenção, nenhum deles confirmou que abre qualquer documentação e sim vai direto ao código fonte resolver o problema. Imagina agora um cenário onde precisa fazer uma mudança, seja qualquer for o tamanho, como terá certeza que não gerou nenhum tipo de impacto no projeto? Não encontrará nenhum documento word que lhe dará essa garantia no código.

Para isso nós usamos outras abordagens no desenvolvimento ágil como TDD (Test Driven Development), orientando o desenvolvimento a testes unitários, gerando uma documentação de negócio no formato de testes que são executados automaticamente, garantindo que aquele código coberto pelos testes não sofreu impacto com a mudança de negócio. Na prática nós desenvolvemos primeiro os testes e depois as regras de negócios, já validando as mesmas com os testes, diminuindo inclusive o tempo de desenvolvimento.

Para alinhar a visão do cliente com as implementações realizadas, temos uma abordagem em desenvolvimento ágil conhecida como BDD (Behavior Driven Development) que permite orientar o desenvolvimento baseando-se no comportamento de negócio desejado escrito em histórias pelo cliente, fortalecendo mais ainda um dos princípios em desenvolvimento ágil que é o valor de negócio.

Para integrar o código fonte desenvolvido usamos a abordagem de CI (Continuous integration), tendo um mecanismo automático para geração de versão e entrega do software funcionando, permitindo uma visibilidade do produto que está sendo entregue e indo além, usando os testes unitários produzidos e outras abordagens para garantir a integridade do código fonte e sua fidelidade aos valores de negócio garantidos dentro dos testes e outros padrões de projeto, como arquitetura em camadas favorecendo a reutilização de software.

A informação mais importante que devemos passar ao nosso cliente é que estamos aptos a fazer mudanças no software e adaptar ao final de cada ciclo para juntos atingirmos os valores de negócio do projeto. Ter o cliente próximo esclarecendo as dúvidas faz a diferença e reduz todo o ruído de diferenças de entendimento, permitindo esclarecer o mais breve possível sempre que aparecer qualquer impedimento ou mudança de rumo.

As pessoas tratadas como pessoas e incentivadas a colaborar produzem cerca de 10 vezes mais, pois são desafiadas a dar o melhor de si e valorizadas pelos resultados proporcionados à equipe de uma maneira rápida, pois com ciclos curtos de projetos conseguirmos alinhar rapidamente qual o resultado de cada equipe de projeto. É muito importante que todos se sintam importantes no processo. Por isso incentivar a participação e compartilhamento de informações resulta em comprometimento.

O desenvolvimento de software como um trabalho criativo e intelectual requer uma atenção dobrada na equipe, motivando e alinhando expectativas, além de iniciativas que valorizem cada entrega de projeto com sucesso, mesmo que seja tirando uma foto da equipe e uma Coca-Cola gelada para cada. Na maioria das vezes a intensão vale mais que a força empregada e, ter um ambiente de trabalho feliz é o maior impulsionador de qualquer projeto.

Compartilhe, escute e provoque criando desafios animadores nas pessoas para que juntas formem uma grande força em prol de uma causa e não de uma regra. Conquiste liderando e multiplique a visão por todos do projeto removendo impedimentos e burocracia que não contribuem em nada com o resultado.

Para ter a melhor estratégia de desenvolvimento em um projeto de software inicie pela formação da equipe e crie mecanismos de qualificação e demais incentivos para manter um grupo forte e orientado a resultados. Acabo por acompanhar muita gente preocupada com quanto tempo uma pessoa está parada na frente do computador e não com o resultado que essa pessoa proporciona ao projeto.

Até hoje venho observando em projetos de “software civis tradicionais” gerentes e analistas estimando atividades para outras pessoas assumirem o compromisso de programar. É logico que sabemos de antemão que os desenvolveres vão concordar e que você já vai dar o prazo sabendo que não será entregue, criando o que eu batizei de mundo “Alice do Software”, onde todos sabem que não vai dar certo, mas continuam vivendo até não aguentarem viver mais dentro do caos e darem o grito de mudança.

De uma vez por todas vamos entender que resultado em um projeto de software se dá pela energia criativa para construir uma solução simples e rápida e não pela quantidade de força empregada ao longo do tempo. Para ter comprometimento é fundamental compartilhar com todos do projeto as informações e objetivos e abrir espaço para escutar e colaborar.

O dia que descobrirem, finalmente, que desenvolvimento de software é empírico, mutável e não pode ser encarado como um projeto de uma obra civil, teremos atitudes diferentes com pessoas felizes desenvolvendo com qualidade desde o início e entregas rápidas alinhando a expectativa de negócio.

Para saber mais:

Fonte: Ramon Durães/IMasters

Google abre código do framework de teste unitário para Javascript

No blog do Google sobre open source, a empresa anunciou o lançamento do JS Test – o framework de teste unitário para javascript que é usado internamente – como um projeto open source. Os testes são executados na engine V8 do Google, o mesmo mecanismo open source usado no navegador do Google Chrome. No desenvolvimento do JS Test, os criadores do framework foram inspirados pelo googletest, um framework open source para escrever testes unitários em C++.

Aaron Jacobs, engenheiro do Google, diz que o JS Test tem uma inicialização e um tempo de execução muito rápidos e que não precisa de um navegador para ser executado. É possível usar um executor de testes em um navegador e ele pode simplesmente ser atualizado quando ocorram mudanças no código do JavaScript. O JS Test também contém um framework embutido para testes isolados de objetos de teste. Seu estilo e sua semântica também são baseadas no googletest.

O site do projeto aponta que a ferramenta não pode ser facilmente usada para testar códigos com funções DOM (Document Object Model), que limita o uso do JS Test para aplicações de web clássicas. Mas a ferramenta parece funcionar bem para códigos que não dependem do DOM e para funções específicas de navegadores, como o window e o document. Por enquanto, ele pode ser usado no servidor e no console de aplicações baseadas no framework server-side Node.js.

A versão mais recente do JS Test é a 1.0.4, e está hospedada no Google Code.

Fonte originalmente publicada em: TheH

Fonte: IMaster

Sete virtudes do Desenvolvimento Direcionado por Testes (TDD)

Não me entenda mal, este não é mais um artigo do tipo “você deve praticar TDD porque…”. Meu objetivo é atingir aqueles que desejam iniciar nisso, mas precisam de um guia sobre como tirar o máximo benefício dele e evitar desastres típicos. Diferentes tipos de testes (e práticas de testes) fornecem benefícios diferentes, e eu pensei que talvez eu pudesse escrever algo a que você possa se referir de tempos em tempos. Portanto, estas são as virtudes prometidas, em ordem cronológica.

01. Testes te ajudam a criar o design da API da sua classe

Você pode ter ideias elaboradas sobre seus métodos e propriedades, mas os usuários que de fato usam suas coisas pensam diferente. Seja o primeiro usuário da sua classe antes de escrevê-la, e você a deixará pronta e correta antes que qualquer pessoa a veja.

02. Testes te ajudam a criar o design da arquitetura do seu sistema

Você acha que é inteligente. Aqueles diagramas DML deixam sua mãe orgulhosa de você. Até você voltar para o seu app depois de um ou dois anos e ter que fazer algumas mudanças. Você descobre alguns métodos LOC 2000, statements goto, e até procedimentos armazenados. Meu Deus, que bagunça!

Não existe prova rigorosa, mas várias fontes nos dizem que designs direcionados para testes são muito mais flexíveis e sustentáveis. Existem muitos motivos para acreditarmos nisso, o que vale até um artigo separado.

De qualquer maneira, se você parar de fingir que é a prova de falhas, e começar a escutar os seus testes, você poderá melhorar o seu design além dos seus sonhos mais improváveis. Isso é considerado o maior benefício do TDD, apesar de não ser óbvio desde o início, pois isso não está diretamente relacionado a testes.

03. Testes te ajudam a implementar os membros da sua classe

Direcionado a testes, seu método eventualmente se torna a coisa mais simples do mundo que funciona. A maior parte do que dissemos acima se aplica ao design no nível de membros também.

04. Com testes, você tem certeza de que sua aplicação ainda vai funcionar corretamente depois que você mudá-la

Depois de fazer uma pequena mudança à implementação subjacente de um certo recurso menor, você testa manualmente todo o sistema… ou seus usuários finais fazem isso por você. De qualquer maneira, você passa o fim de semana tentando entender os dados corrompidos de um backup que você fez acidentalmente alguns dias atrás (não estou inventando isso, realmente aconteceu comigo!).

Testes, quando feitos apropriadamente, podem ser uma rede de proteção que te protege de acidentes infelizes. Você pode refatorar seu código livremente com o objetivo de melhorar o seu design, sem ter medo de introduzir um bug de regressão.

05. Testes documentam a sua API

Ao estruturar seus testes em volta de classes (o que não é a melhor ideia, mas é ok para começar), você pode olhar para um teste em particular e compreender o que o método correspondente faz. Isso é, se o teste estiver nomeado e escrito devidamente.

06. Testes documentam o seu sistema

Isso não quer dizer a mesma coisa que o falado no tópico anterior. Ao olhar para um sistema novo, estou tentando entender como fazer as coisas com ele, não o que uma classe em específico faz. Portanto, ao estruturar os seus testes em volta de recursos do sistema, você fornece uma boa maneira para documentar seu comportamento, “como usar o recurso x” e “o que acontece se eu de fato usá-lo”.

Já deram sete?

Se você souber de outros benefícios, por favor, escreva-os nos comentários!

Ok, e agora?

Espero que você não use o TDD só porque te falaram para usar, mas porque você quer tirar vantagens dele. Agora que você conhece esses benefícios, você não os usa cegamente. Você tenta escrever seus testes de modo que eles deixem a refatoração mais fácil, não difícil. De modo que eles de fato influenciem seu design, e não o contrário. De modo que eles sejam fáceis de entender, e façam com que você compreenda o sistema mesmo se for um completo estranho.

Como você consegue isso? Ah, isso é outra história.

Texto original disponível em http://ivonna.biz/blog/2011/6/10/seven-virtues-of-test-driven-development.aspx

Fonte: IMaster