Por que o teste do MVC Views é desaprovado?

Atualmente, estou preparando as bases para um aplicativo ASP.Net MVC e estou analisando que tipo de testes de unidade devo estar preparado para escrever. Eu já vi em vários lugares pessoas dizendo essencialmente 'não se incomode em testar seus pontos de vista, não há lógica e é trivial e será coberto por um teste de integração'.

Não entendo como isso se tornou a sabedoria aceita. Os testes de integração têm uma finalidade totalmente diferente dos testes de unidade. Se eu quebrar alguma coisa, não quero saber meia hora depois, quando meus testes de integração forem interrompidos, quero saber imediatamente.

Cenário de exemplo: digamos que estamos lidando com um aplicativo CRUD padrão com uma entidade do Cliente. O cliente tem um nome e um endereço. Em cada nível de teste, desejo verificar se a lógica de recuperação do Cliente obtém o nome e o endereço corretamente.

Para testar o repositório da unidade, escrevo um teste de integração para acessar o banco de dados. Para testar as regras de negócios, eu zombei do repositório, alimentei os dados apropriados das regras de negócios e verifiquei se meus resultados esperados foram retornados.

O que eu gostaria de fazer: Para testar a unidade da interface do usuário, zombei das regras de negócios, configurei minha instância esperada do cliente, renderize a exibição e verifique se a exibição contém os valores apropriados para a instância especificada.

O que estou parado de fazer: Para testar o repositório da unidade, escrevo um teste de integração, configuro um login apropriado, crie os dados necessários no banco de dados, abra um navegador, navegue até o cliente e verifique se a página resultante contém as informações apropriadas. valores para a instância que especifiquei.

Percebo que há sobreposição entre os dois cenários discutidos acima, mas a principal diferença é o tempo e o esforço necessários para configurar e executar os testes.

Se eu (ou outro desenvolvedor) remover o campo de endereço da exibição, não quero esperar que o teste de integração descubra isso. Eu quero é descoberto e sinalizado em um teste de unidade que recebe várias vezes ao dia.

Tenho a sensação de que não estou entendendo algum conceito-chave. Alguém pode explicar por que é ruim desejar um feedback imediato do teste sobre a validade de uma exibição do MVC? (ou se não for ruim, não é a maneira esperada de obter esse feedback)

O teste simples da interface do usuário é bastante fácil no ASP.NET MVC. Basicamente, tudo o que você precisa fazer é afirmar que o HTML retornado contém os elementos necessários. Embora isso garanta que a página HTML esteja estruturada da maneira esperada, ela não testa completamente a interface do usuário.

O teste adequado da interface do usuário da web requer uma ferramenta como o Selenium, que usa navegadores em sua máquina e garante que o JavaScript e o HTML estejam funcionando corretamente em todos os navegadores. O Selenium possui um modelo de cliente / servidor para que você possa ter um conjunto de máquinas virtuais com clientes Unix, Mac e Windows e o conjunto de navegadores comuns a esses ambientes.

Agora, um aplicativo MVC bem projetado (padrão, não estrutura) coloca a lógica importante nos modelos e controladores. Em resumo, a funcionalidade do aplicativo é testada quando você testa esses dois aspectos. As visualizações tendem a ter apenas lógica de exibição e são facilmente verificadas com inspeção visual. Devido ao fino processamento na visualização e a maior parte do aplicativo ser bem testada, muitas pessoas não pensam que a dor de testar a camada de visualização supera os benefícios obtidos por ela.

Dito isto, o MVC possui algumas boas instalações para verificar o DOM retornado pela solicitação. Isso reduz bastante a dor ao testar a camada de visualização.

Eu não diria que é desaprovado. Em vez disso, esse sentimento é o resultado do fato de que as exibições MVC de teste de unidade (pelo menos da variedade aspx) são bastante difíceis, porque as exibições aspx dependem demais dos WebForms, que são bastante testáveis. Portanto, argumenta-se que não vale a pena o esforço, porque as visões tendem a não ser tão complicadas.

É claro que as visualizações podem ficar bastante complicadas, por isso é sua escolha.

Não tenho certeza de que isso seja mal visto. A testabilidade é um dos principais benefícios do uso do ASP.NET MVC. Confira o blog de Steve Sanderson para obter mais informações sobre isso.

Ele também escreveu o melhor livro ASP.MVC (IMO) do mercado. Ele não apenas ensina MVC, mas também vai além para ensinar as melhores práticas, incluindo práticas de teste.

Acho que preciso esclarecer um pouco as visualizações de teste de unidade - você pode criar testes de unidade em torno do resultado retornado do controlador (ActionResult, etc.). Você ainda precisará fazer outros testes para a interface do usuário e a interação reais.

Você pode aprender como testar a Visualização retornada por uma ação do controlador, como testar os Dados da Visualização retornados por uma ação do controlador e como testar se uma ação do controlador o redireciona ou não para uma segunda ação do controlador, confira o seguinte URL, descreva neste breve artigo sobre o teste de exibição de dados no MVC .