InfoQ

Notícias

Testes: O que os desenvolvedores devem fazer vs o que eles fazem atualmente

Postado por Jonathan Allen , traduzido por Felipe Rodrigues em 11 Nov 2008 04:33 PM

Comunidade
Agile,
.NET
Tópicos
Testes Unitários
Tags
Testes

No PDC tivemos um painel de discussão sobre "O futuro do Teste Unitário". A maior parte da conversa focou em mocking. Foi um consenso geral frameworks de mock estão sendo super utilizados.

A teoria é a seguinte. Freqüentemente, implementar todas as interfaces necessárias é tedioso ou consome muito tempo. Então para tornar as coisas mais fáceis, as pessoas apelam para os frameworks de mocking. Isso apenas esconde o problema raiz, que é uma API muito complexa.

Um tema popular foi a diferença entre "teste de desenvolvedor" e teste que todo mundo faz. A idéia de que desenvolvedores escrevem somente testes unitários era freqüente na discussão. Testar de acordo com os requisitos, testes de aceitação, testes de integração e todas as outras formas de teste são problemas de alguém fora do desenvolvimento.

Isso ressalta uma incompreensão na comunidade de testes unitários. Especialmente, o pressuposto de que todos os desenvolvedores têm um time de QA para cuidar de todos os outros tipos de teste. Infelizmente, mesmo empresas multimilionárias freqüentemente não possuem um time de QA, deixando todo o teste para o desenvolvedor e o usuário final.

A principal desculpa para não suportar mais tipos de testes foi a velocidade. Testes unitários já são lentos e, portanto não há espaço para testes mais lentos que incluem comunicação via rede. Ainda pior é o fato de que nenhuma outra opção foi considerada.

Por exemplo, testes unitários podem ser inteligentes. É possível usar os resultado de cobertura de código para executar os testes somente para os códigos que mudaram. Mudar uma classe não deve exigir que você execute a suíte de teste inteira. O termo "teste unitário " implica que você pode testar somente um pequeno pedaço.

Outra possibilidade que não tem sido discutida é alavancar a programação distribuída. O código e os testes podem ser rapidamente carregados para diversos servidores e executados neles. Nós já temos toda a tecnologia necessária para execução de integração contínua.

No começo do painel, reconheceu-se que bancos de dados estão sendo negligenciados. A maioria dos desenvolvedores de banco de dados tem pouco ou nenhum conceito sobre testes unitários e há pouquíssimas ferramentas para suportá-los. Mais perturbador, nem foram questionados para vir à mesa do painel. Infelizmente isso foi tudo que foi dito sobre eles. Em nenhum momento o painel ofereceu opções reais para corrigir os problemas sociais.

Do lado positivo, houve alguma discussão sobre usar ferramentas de modelagem para tornar os testes unitários mais fáceis. Há muitas opções aqui como iniciar no nível de contratos. Os contratos poderiam então ser usados pelos geradores de código para escrever os testes. Obviamente isso não seria uma solução 100%, mas iria reduzir o esforço em cenários comuns.

Outra idéia promissora foi a de delta state management. A maioria das pessoas assume que um teste de contas começa com $100 e depois da transação só tem $80. A alternativa é primeiro ler o balanço atual e então checar para ver se houve a redução de $20. Desta forma um reconfiguração completa do ambiente de teste não necessária para cada execução.

Delta State Management por João José Pedrini Enviado Nov 12, 2008 6:43 AM
Re: Delta State Management por Felipe Rodrigues Enviado Nov 12, 2008 7:36 AM
  1. Voltar ao topo

    Delta State Management

    Nov 12, 2008 6:43 AM por João José Pedrini

    O que seria "delta state management"? Acabo de procurar no google e encontro "Resultados 1 - 6 de 6 para "delta state management" (0,60 segundos)". Você inventou isto ou há alguma teoria por trás?

  2. Voltar ao topo

    Re: Delta State Management

    Nov 12, 2008 7:36 AM por Felipe Rodrigues

    O que seria "delta state management"? Acabo de procurar no google e encontro "Resultados 1 - 6 de 6 para "delta state management" (0,60 segundos)". Você inventou isto ou há alguma teoria por trás?
    Eu só traduzi e como não vi sentido em traduzir para gerenciamento de estado delta. Por isso, postei a mesma dúvida na versão em inglês, pro autor responder. =) http://www.infoq.com/news/2008/10/Testing#view_35002

Conteúdo Educacional

13 Razões para Programadores Java aprenderem Flex e BlazeDS

Treze razões para que programadores java aprendam Flex e BlazDS. Ele discute sobre o porquê que Flex e BlazeDS é uma das melhores opções para desenvolver aplicações ricas de internet.

Ruby in Practice com Jeremy McAnally

Rob Bazinet e Matthew Bass, ambos da InfoQ, tiveram a oportunidade de conversar com Jeremy McAnally, sobre o livro "Ruby in Practice" no qual foi co autor junto à Assaf Arkin.

Esclarecendo os Equívocos Mais Comuns Sobre Refatoração

Danijel Arsenovski tenta esclarecer alguns mitos sobre refatoração e como isso se aplica para desenvolvedores .NET

As 10 Maiores Mudanças no Flex 4

Em maio, Adobe lançou a primeira versão beta do Flex 4, codinome Gumbo. A lista a seguir proporciona uma visão geral de alto nível dos itens que foram modificados na última versão do framework RIA.

Conversa sobre RubyMine e JetBrains

Um dos anúncios mais interessantes recentemente feito à comunidade Ruby foi o lançamento da IDE JetBrains RubyMine para aplicações Ruby e Ruby on Rails.

Introdução à Data Services

Data Services são serviços de software que encapsulam operações das entidades chave relevantes para a empresa.

Esquemas para Web Services – Parte 1: Tipos de dados básicos.

O uso do XML traz consigo desvantagens, como problemas em potencial com desempenho, mas também oferecem um nível de abstração que permite diminuir o acoplamento entre as partes envolvidas na troca.

Revisão do livro: Clean Code: A Handbook of Agile Software Craftsmanship

Como programadores, a nossa primeira prioridade é criar código que funciona. Infelizmente, código que simplesmente “funciona” não é suficiente.