Teste unitário com Selenium WebDriver (Simples exemplo com o Chrome e Firefox)

O vídeo(Selenium WebDriver - Install + Hello World with Visual Studio, C#)  é um ótimo passo a passo de como utilizar o Selenium Webdriver com uma aplicação c#.

Para demonstrar, adicionei ao GitHub um simples exemplo de teste unitário fazendo uma busca no Bing utilizando Chrome e Firefox.

As dependências dos projeto foram instaladas com o Nuget utilizando os seguintes comandos:
Install-Package Selenium.WebDriver
(Pacote básico para permitir o Selenium Webdriver e o firefox)

Install-Package Selenium.WebDriver.ChromeDriver
(Pacote para permitir os testes com o Chrome)

O código acontece no método SearchAndNavigateTest, que basicamente abre a url do Bing, busca pela palavra chave "aplicacoesweb selenium" e clica no primeiro link que contiver "aplicacoesweb.blogspot" no atribute href.

Este código é executado no FireFox e no Chrome no teste unitário TestMethod1()

Caching (OutputCacheAttribute e DonutCachingAttribute)

O OutputCacheAttribute, atributo nativo no ASP.NET MVC, permite que façamos cache de resultados de actions para futuras respostas às requisições dos usuários. Há várias opções de configuração e é sugerido de se utilizar esse artifício quando você precisa otimizar o desempenho de sua aplicação.

Otimizar desempenho é uma tarefa que deve ser feita de maneira muito criteriosa. Primeiro é importante você saber qual o problema atual a ser resolvido e as métricas da situação, por exemplo, está consumindo muito processamento determinada action (Atinge 100% de CPU, gasta muita memória e/ou demora muito tempo para retorno ao usuário). Deve-se tomar o cuidado para não aplicar uma solução de cache que poderá resolver os problemas anteriores, mas acabar gerando um outro problema de consumo de memória por manter as informações em cache. Por isso a importância das métricas antes e depois de aplicar a solução.

Decidindo pela aplicação do OutputCacheAttribute é importante ainda saber que ele gera um cache respeitando configurações de variação por action do Controller, por tempo (Duration), por parâmetros de unicidade (VaryByContentEncoding, VaryByCustom, VaryByHeader, VaryByParam) e por local (Client, Downstream, Server). Se for decidido que o cache será no servidor é importante saber que futuras requisições nas condições de unicidade configuradas anteriormente receberá a informação do cache completa, ou seja, se o cache foi criado pela requisição de um usuário com perfil de administrador (que tem mais opções de menu que um usuário comum), todos os usuários ao requisitarem a página em cache irão ver a página como o administrador (com as opções de menu que não deveria ver).

Se você tiver essa situação, para resolvê-la, há a teoria de cache chamada de Donut Hole Caching, que basicamente você pode escolher qual a parte do conteúdo deseja fazer cache e/ou qual deve ser atualizada automaticamente pelo contexto do usuário requisitante, este artigo em inglês explica a teoria de maneira detalhada e lúdica.

Há uma implementação de pacote para utilizar o Donut Hole Caching no pacote Nuget MvcDonutCaching que também tem o fonte disponível no Github. Neste artigo há uma explicação de todas as dificuldades e escolhas feitas para viabilizar a implementação, mas basicamente a grande sacada é que utilizando o pacote, é possível definir ChildActions como dinâmicas para serem carregadas, mesmo quando o resto da página está em cache. Para viabilizar isso o pacote adiciona  comentário HTML para marcar pontos de atualização de parte de conteúdo nas próximas requisições, quando utilizado as extensões @HtmlAction(), @Html.RenderAction() e definindo o parâmetro excludeFromParentCache, conforme código abaixo:

O ActionFilter (DonutOutputCacheAttribute) irá atualizar esses "buracos" no método OnResultExecuted.

Como está a preocupação do ASPNET 5(Core) em relação a desempenho?

No vídeo abaixo, com data de 4 de novembro de 2015, Damian Edwards fala sobre o desempenho do ASP.NET. Tanto em relação o quão era ruim o ASP.NET 4.6 e inferiores e o quanto poderá ser bom o ASP.NET 5.

Talvez a motivação para essa preocupação seja o que foi citado no vídeo: o trabalho publicado no site https://www.techempower.com/benchmarks/ . A ideia do trabalho é :

"This is a performance comparison of many web application frameworks executing fundamental tasks such as JSON serialization, database access, and server-side template composition. Each framework is operating in a realistic production configuration. Results are captured on Amazon EC2 and on physical hardware. The test implementations are largely community-contributed and all source is available at the GitHub repository."

"Isto é fazer comparação de desempenho de várias frameworks de aplicação web executando tarefas fundamentais como serialização de JSON, acesso a base de dados, e composição para server-side template. Cada framework está operando numa configuração de produção realista. Resultados são capturados no Amazon EC2 e num hardware físico. As implementações de testes são amplamente contribuídas pela comunidade e todos os códigos estão disponívels no repositório GitHub."
(Tradução livre do autor)

No vídeo o Damian ainda cita todos os pontos que podem impactar no desempenho da aplicação:

• Startup Time (Tempo para carregar a aplicação
• Troughput (Quantas requisições minha aplicação por atender)
• Latency/Response Time (Afeta a experiência do usuário, quando você envia algo e espera o retorno do servidor)
• Scale (Concorrência)
• Working set (Sobrecarga de memória)

O Damian vem publicando resultados do trabalho no Github:
https://github.com/aspnet/benchmarks