Como faço para testar a unidade de um site de formulários da web?

Como faço para testar a unidade de um site de formulários da web? Parece-me que, como muito disso depende do estado e da entrada do usuário, não seria viável.

Se não for possível, existe uma alternativa automatizada válida?

Sim você pode. Você só precisa ter cuidado para separar bem suas preocupações. Em resumo, você precisa remover toda a sua lógica do code-behind e colocá-la em outras classes.

Existem duas maneiras comuns de fazer isso.

A maneira mais simples é repensar todos os manipuladores de eventos em termos de "Quais informações o sistema me fornece? Quais informações eu preciso preencher na página?" e, em seguida, forneça uma classe de serviço que faça essa conversão.

Nesse caso, a camada de serviço deve saber muito pouco sobre a natureza da sua camada de apresentação. Você ainda precisa pegar os dados retornados do serviço e preencher os componentes corretos do formulário da Web em seu code-behind e isso permanece não testado (pelo menos por testes de unidade, você ainda pode empregar testes de integração). Mas raramente é onde o código dá errado, é muito mais provável que falhe na lógica.

Uma maneira mais complicada, mas mais eficaz, é usar o padrão Model View Presenter . Quando tentamos isso, descobrimos que os apresentadores rapidamente se tornaram muito acoplados à estrutura e, quanto mais desenvolvíamos o MVP, mais claro era que o MVP realmente queria ser MVC, mas não podia.

Dito isto, outros fizeram isso com muito sucesso - há até uma estrutura webformsmvp disponível para remover o trabalho pesado - portanto, sua milhagem pode variar.

Obviamente, uma página inteira de formulários da web não é uma unidade e, portanto, não pode ser testada. No entanto, há algumas coisas que você pode fazer para testes automatizados:

• teste de unidade de componentes individuais da página (qualquer método que execute lógica real)
• componentes de teste de unidade usados ​​pela página (controles personalizados, lógica de negócios subjacente etc.)
• teste de funcionalidade automatizado (controlando remotamente um navegador ou enviando solicitações HTTP através de algo como cURL)
• teste de penetração automatizado (existem ferramentas que tentam encontrar possíveis pontos de injeção e executam automaticamente ataques de injeção inofensivos e detectáveis ​​em sua página)
• teste de carga
• verificação do layout em relação a uma lista de pontos de usabilidade e estilo de marcador (embora isso seja muito difícil de automatizar; geralmente é mais viável fazê-lo manualmente de vez em quando)

Sinto muito por ter perdido a parte "unit" da pergunta ...

SeleniumHQ é seu amigo para testes no front-end. Não é um teste de unidade, mais como um teste de caixa preta. Você ainda precisa pensar em casos de teste válidos ...

Falando por experiência própria: Somente se for bem feito. Por "certo", quero dizer o mínimo de code-behind e algo como o Model-View-Presenter acima mencionado para tornar o formulário da Web "burro". Isso geralmente se mostra muito difícil com aplicativos brownfield porque eles não foram projetados com isso em mente e é um esforço quase hercúlea refatorar / reescrever páginas para usá-lo.

watin

Acho que os testes unitários da Web são extremamente úteis, mesmo que seja apenas para dar uma idéia geral de um erro de regressão ou para novos projetos.

No que diz respeito ao estado, você cria seus testes de unidade como faria com os testes que não são da interface do usuário - eles limpam o banco de dados no início do teste e reconstroem o banco de dados para conter nada, exceto o estado inicial. Cada teste de unidade encapsula uma única página, ou geralmente uma tarefa distinta em uma página.

http://watin.org/ é outra ferramenta de teste da Web, mas para C # / .NET. Você escreve os testes como testes de unidade:

[Test] 
public void SearchForWatiNOnGoogle()
{
  using (var browser = new IE("http://www.google.com"))
  {
    browser.TextField(Find.ByName("q")).TypeText("WatiN");
    browser.Button(Find.ByName("btnG")).Click();

    Assert.IsTrue(browser.ContainsText("WatiN"));
  }
}

Atualmente, ele é baseado no IE, mas possui suporte experimental para Firefox e Chrome. Você pode praticamente automatizar tudo o que faria nos testes manuais, incluindo a interação Javascript.

Você não pode realmente testar um site na unidade, simplesmente porque as solicitações ocorrem em uma conexão (ou através de uma pilha TCP). Assim, os testes não se enquadram na definição de "teste de unidade"; seriam, provavelmente, testes de ponta a ponta.

Para esses tipos de testes, você pode usar um conjunto como o Selenium, que executa um navegador da web nos bastidores. Uma palavra de alerta: geralmente esse tipo de teste é muito difícil e imprevisível, pois existem muitas partes móveis!

Mais interessante, porém, me preocupa um pouco porque você precisaria testar os formulários da Web. Você não está colocando muita lógica no código por trás e tem uma lógica de negócios anêmica por acaso?

Jasmim

Nos últimos 5 anos, o Jasmine emergiu como uma ferramenta essencial para testes de unidade front-end. Geralmente é incorporado ao teste de construção automático com Node e npm

Por https://en.wikipedia.org/wiki/Jasmine_(JavaScript_testing_framework) :

Jasmine é uma estrutura de teste de código aberto para JavaScript. [2] Seu objetivo é executar em qualquer plataforma habilitada para JavaScript, não se intrometer no aplicativo nem no IDE e ter uma sintaxe de fácil leitura. É fortemente influenciado por outras estruturas de teste de unidade, como ScrewUnit, JSSpec, JSpec e RSpec. [3]

Apesar de todas as menções ao javascript, ele também pode ser usado para testes de unidade de um formulário da Web simples.

ASP.NET

Ao desenvolver um site ASP.NET, pudemos executar testes de unidade em:

• O domínio
• Controladores / apresentadores BL
• o código por trás das páginas de formulários da Web

É possível TDD tudo isso, dependendo da sua arquitetura. A única coisa que você não pode testar na unidade é o layout do arquivo de marcação.