Dica Rápida: Testes Mesclados ao Projeto

Olá!

Esta é mais uma Dica Rápida, e está será bem rápida mesmo, e vamos falar sobre como utilizar um recurso muito comum em outras linguagens como Rust↳Rust7 conteúdosDesmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Como criar seu primeiro Programa em Rust com Solana PlaygroundDev (Back & Front) · mai 2026Rust no ranking: a segurança de memória perdeu a guerra corporativa?Marketing Tech · abr 2026Ver tudo em Dev (Back & Front) →, Go e TypeScript: testes que convivem com as classes que validam.

Vamos lá!

Nada Convencional

Em C# o padrão é criar um projeto de testes e, nele, replicar a organização do projeto principal e implementar classes que tenham as de negócio como alvo.

Isso tem sido assim desde sempre mas é possível mudar essa abordagem e fazer com que seus testes convivam com as demais em um único projeto.

Mas fica a pergunta: faz sentido? Vou me adiantar na resposta e dizer: faz!

Se você leu meu post sobre Ports, Adapters & Vertical Slices já sabe das vantagens de manter próximo aquilo que é comum e, por isso, faz muito sentido que esse princípio se estenda aos testes.

Como fazer?

Como disse essa dica vai ser bem rápida.

Abra o arquivo do seu projeto e informe o seguinte:

<ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Testing" Version="10.0.12" PrivateAssets="All" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="18.10.0" PrivateAssets="All" />
    <PackageReference Include="xunit" Version="2.9.3" PrivateAssets="All" />
    <PackageReference Include="xunit.runner.visualstudio" Version="4.0.0">
        <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
        <PrivateAssets>all</PrivateAssets>
    </PackageReference>
</ItemGroup>

<ItemGroup Condition="'$(Configuration)' == 'Release'">
    <Compile Remove="**/*Test.cs" />
</ItemGroup>

Poderíamos encerrar o post aqui e dizer que tudo vai funcionar e me despedir, mas há dois detalhes interessantes que vale a pena comentar.

PrivateAssets

Esse é um atributo muito curioso, ele informa ao compilador para não incluir o referido pacote como referência para projetos que dependam do configurado. Ou seja, se seu projeto tem uma dependência, como no caso acima os pacotes de testes xUnit e Microsoft.NET.Test.Sdk, eles não serão passados como dependências a outro projeto caso sua aplicação seja referenciada.

Imagine que, por exemplo, você tem um projeto que representa seu modelo de domínio e outro que representa uma API que vai expor alguns de seus comportamentos. Pois bem, se você referenciar o projeto de domínio com as classes de teste, no momento da compilação eles não serão exportados para o projeto da Web API.

Legal. Não?

Só que isso cria um problema: como suas classes de teste dependem desses pacotes o seu projeto Web API vai quebrar na compilação.

Como resolvemos isso?

Condition

Esse é outro atributo interessante porque ele nos permite adicionar uma condição à compilação que, neste nosso caso, é a configuração do build.

Se o build estiver configurado para o modo Debug nossas classes de teste serão aproveitadas e as dependências das classes de teste vão funcionar normalmente.

Entretanto, se a configuração de build estiver em modo Release, todas as classes de teste serão removidas da compilação. Ou seja: a referência ao seu projeto não quebrará mais porque não haverá nenhuma dependência dos frameworks de testes que foram suprimidos.

Bom demais. Né?

E acabou!

Por hoje é isso. Se você quiser ver essa técnica em funcionamento, segue o código no Github.

Me diz o que achou depois de testar? Pode ser por um comentário aqui no Blog ou em uma das minhas redes sociais.

Nos vemos no próximo post!