Melhores práticas para integrar o TDD ao desenvolvimento de aplicações web?

Question

Testes unitários e aplicações web ASP.NET são um ponto ambíguo no meu grupo.Na maioria das vezes, boas práticas de teste falham e os aplicativos da web acabam ficando no ar por vários anos sem nenhum teste.

A causa desse problema geralmente gira em torno do incômodo de escrever a automação da UI no meio do desenvolvimento.

Como você ou sua organização integram as melhores práticas de TDD ao desenvolvimento de aplicações web?

Answer 1

O teste de unidade será possível se você separe suas camadas adequadamente.Como Rob Cooper sugeriu, não coloque nenhuma lógica em seu WebForm além da lógica para gerenciar sua apresentação.Todas as outras camadas lógicas e de persistência devem ser mantidas em classes separadas e então você pode testá-las individualmente.

Para testar a GUI, algumas pessoas gostam selênio.Outros reclamam que é difícil configurar.

Answer 2

Eu coloco o aplicativo em camadas e pelo menos o teste de unidade do apresentador/controlador (qualquer que seja sua preferência, mvc/mvp) para a camada de dados.Dessa forma, tenho uma boa cobertura de testes na maior parte do código escrito.

Eu olhei para FitNesse, Watin e Selenium como opções para automatizar os testes de UI, mas ainda não consegui usá-los em nenhum projeto, então continuamos com os testes humanos.FitNesse era o que eu estava inclinado, mas não consegui apresentar isso tão bem quanto apresentar o TDD (isso me deixa mal?Espero que não!).

Answer 3

Esta é uma boa pergunta, que também irei subscrever :)

Ainda sou relativamente novo no desenvolvimento web e também estou vendo muitos códigos que ainda não foram testados.

Para mim, mantenho a UI o mais leve possível (normalmente apenas algumas linhas de código) e teste todo o resto.Pelo menos posso ter alguma confiança de que tudo o que chega à IU está tão correto quanto possível.

É perfeito?Talvez não, mas pelo menos ainda é altamente automatizado e o código principal (onde acontece a maior parte da "mágica") ainda tem uma cobertura muito boa.

Answer 4

Geralmente, eu evitaria testes que envolvessem depender de elementos da interface do usuário.Eu sou a favor do teste de integração, que testa tudo, desde a camada do banco de dados até a camada de visualização (mas não o layout real).

Tente iniciar um conjunto de testes antes escrever uma linha de código real em um novo projeto, pois é mais difícil escrever testes posteriormente.

Escolha cuidadosamente o que você testa - não escreva testes para tudo sem pensar.Às vezes é uma tarefa chata, então não a torne mais difícil.Se você escrever muitos testes, corre o risco de abandonar essa tarefa sob o peso de uma manutenção demorada.

Tente agrupar o máximo de funcionalidades possível em um único teste.Dessa forma, se algo der errado, os erros se propagarão de qualquer maneira.Por exemplo, se você tiver uma classe geradora de resumo - teste a saída real, não todas as funções auxiliares.

Não confie em si mesmo.Suponha que você sempre cometerá erros e, por isso, escreve testes para tornar sua vida mais fácil, não mais difícil.

Se você não se sente bem em escrever testes, provavelmente está fazendo errado;)

Answer 5

Uma prática comum é mover todo o código possível do codebehind para um objeto que você possa testar isoladamente.Esse código geralmente seguirá os padrões de design MVP ou MVC.Se você pesquisar por "Rhino Igloo" provavelmente encontrará o link para seu repositório Subversion.Vale a pena estudar esse código, pois demonstra uma das melhores implementações de MVP em Web Forms que já vi.

Seu codebehind irá, ao seguir esse padrão, fazer duas coisas:

1. Transita todas as ações do usuário para o apresentador.
2. Renderizar dados fornecidos pelo apresentador.

O teste de unidade do apresentador deve ser trivial.

Atualizar:Rinoceronte Iglu pode ser encontrado aqui: https://svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-igloo/

Answer 6

Houve tentativas de fazer com que o UI Automation gratuito da Microsoft (incluído no .NET Framework 3.0) funcionasse com aplicativos da web (ASP.NET).Acontece que uma empresa alemã chamada Artiso escreveu um post no blog que explica como conseguir isso (link).

No entanto, a postagem do blog deles também vincula webcasts do MSDN que explicam o UI Automation Framework com winforms e depois de dar uma olhada nisso, percebi que você precisa do AutomationId para obter uma referência aos respectivos controles.No entanto, em aplicações web, os controles não possuem um AutomationId.

Perguntei a Thomas Schissler (Artiso) sobre isso e ele explicou que essa era uma grande desvantagem do InternetExplorer.Ele fez referência a uma tecnologia mais antiga da Microsoft (MSAA) e esperava que o IE8 fizesse isso melhor.

No entanto, eu também estava experimentando o Watin e parece funcionar muito bem.Gostei até do Wax, que permite implementar casos de teste simples por meio de planilhas do Microsoft Excel.

Answer 7

Ivona pode testar sua visão.Eu ainda recomendaria mover a maior parte do código para outras partes.No entanto, alguns códigos apenas pertence lá, como referências a controles ou manipuladores de eventos de controle.