Otimizando os testes de uma aplicao .NET em mais de 90%

Recentemente abri uma caixa de perguntas no meu Instagram @fructuoso.dev sobre testes de unidade e me fizeram a seguinte pergunta:

Qual a diferena entre ClassFixture e CollectionFixture?

Para entendermos a diferena entre os dois, primeiro precisamos ter em mente que o xUnit trabalha diferente dos demais frameworks de testes (se voc quiser conhecer um pouco mais sobre esses frameworks recentemente escrevi um artigo comparando os trs).

Entender o ciclo de vida dele pode impactar significante o tempo de execuo dos seus testes, neste artigo veremos um cenrio onde conseguimos reduzir o tempo de execuo em mais de 90%.

Imaginem que temos as seguintes classes de testes em nosso projeto:

Cada uma das duas classes (ClasseA e ClaseB) possuem dois cenrios de testes (chamados apenas para fins de explicao de Teste1 e Teste2).

Diferentemente do MSTest e do nUnit, o xUnit ir criar uma instancia da classe para executar cada um dos cenrios de teste.

Desta forma teremos algo mais ou menos assim:

Sabendo disso fcil associar que, para cada cenrio de teste temos uma nova chamada ao construtor e um escopo totalmente isolado entre os cenrios (que por padro rodam em paralelo).

Onde que entram as Fixtures ento?

Imaginem que para um determinado conjunto de cenrios de testes queremos compartilhar recursos ou estados, o compartilhamento de estado mais comum para testes integrados pois testes de unidade devem ser totalmente isolados e independentes. Porm em testes de unidade comum precisar reutilizar algum recurso que possua um alto custo para instanciar como por exemplo uma WebAPI ou um DbContext do EntityFramework.

O ClassFixture utilizado sempre que queremos compartilhar tais recursos com outros cenrios de teste de uma mesma classe.

J o CollectionFixture utilizado sempre que queremos compartilhar os recursos com cenrios de testes de classes distintas.

Imaginem que temos o seguinte cenrio:

O FixtureX um ClassFixture, enquanto o FixtureZ um CollectionFixture, teramos ento algo mais ou menos assim:

Enquanto os recursos presentes na FixtureX so compartilhados apenas pelos cenrios de teste de uma mesma classe. Os recursos presentes na FixtureZ sero compartilhados por TODOS os cenrios de testes nas classes que estiverem associadas a ela.

Para recursos em que necessrio o isolamento e que apenas o prprio cenrio de teste o recomendado colocar o recurso na prpria classe que implementa o cenrio de teste.

Ao colocar o exemplo apresentado para rodar teremos algo mais ou menos assim (o resultado pode mudar de acordo com a execuo, pois lembre que os testes rodam assincronamente)

FixtureZ.Construtor    FixtureX.Construtor        ClasseA.Construtor            ClasseA.Teste1        ClasseA.Dispose        ClasseA.Construtor            ClasseA.Teste2        ClasseA.Dispose    FixtureX.Dispose    FixtureX.Construtor        ClasseB.Construtor            ClasseB.Teste1        ClasseB.Dispose        ClasseB.Construtor            ClasseB.Teste2        ClasseB.Dispose    FixtureX.DisposeFixtureZ.Dispose

Entendido o que so e como funcionam as Fixture, vamos avaliar o seguinte cenrio:

• Temos um projeto WebAPI em que temos alguns Controllers;
• Precisamos testar nossa WebAPI de forma integrada usando o Microsoft.AspNetCore.Mvc.Testing (com ajuda dele ns conseguimos levantar uma instncia da nossa WebAPI em tempo de execuo para que ela seja chamada via HTTP em nossos cenrios de testes)

O comparativo foi feito utilizando a seguinte abordagem.

Em nossa API temos um mtodo que recebe um objeto atravs de uma chamada POST, passa por todas as camadas da aplicao at chegar em um banco de dados utilizando Entity Framework InMemory.

A quantidade de cenrios representada pela execuo do mesmo mtodo passando entradas diferentes.

Ento foram explorados dois cenrios, o primeiro usando uma instncia compartilhada entre os cenrios atravs do conceito de Fixture, j o segundo foi implementado com uma instncia dedicada gerada atravs do construtor da classe.

Ao simular algumas execues chegamos aos seguintes cenrios:

Como dito anteriormente as fixtures podem ser utilizadas para compartilhar recursos e estado, dependendo do cenrio em que est sendo implementado pode gerar uma grande diferena de performance, porm em outros casos, o compartilhamento de recursos pode gerar efeitos colaterais no resultado dos testes, visto que os testes so executados ao mesmo tempo, logo se uma varivel for modificada / consumida por mais de um teste ao mesmo tempo o resultado do teste pode variar a cada execuo, ferindo assim um dos princpios bsicos dos testes de unidade.

Espero que vocs tenham gostado do contedo, no deixem de deixar um like e me seguir para que no percam nenhum contedo.

Repositrio GitHub