Forem: Víctor Fructuoso

Criando um CRUD do ZERO em .NET usando o Liquid Framework

Víctor Fructuoso — Tue, 16 Aug 2022 23:29:40 +0000

O Liquid é um framework Open Source desenvolvido pela Avanade, para acelerar o desenvolvimento de aplicações cloud-native em .NET.

Neste artigo, serão utilizadas apenas ferramentas de linha de comando e todos os passos podem ser realizados em qualquer setup que seja compatível com o dotnet (inclusive o artigo foi elaborado usando o WSL2 com Ubuntu)

Para a construção do nosso CRUD vamos começar instalando o Liquid.Templates, que irá nos apoiar no processo de criação do projeto.

Pré-Requisitos

.NET 5 (no momento em que este artigo foi escrito esta era a versão mais recente do .NET compatível com o Liquid)

Instalando o Liquid.Templates

dotnet new -i Liquid.Templates

Caso você já possua o Liquid.Templates instalado, recomendo a atualização do mesmo, para garantir que estamos trabalhando com a versão mais atual.

dotnet new --update-apply

Para ter certeza que o Liquid.Templates foi instalado com sucesso vamos executar o seguinte comando:

dotnet new Liquid -l

Como explorar o Liquid.Templates

Caso o template tenha sido instalado corretamente, você deverá ter um retorno semelhante ao apresentado abaixo:

Na imagem acima, temos a relação de todos os templates que foram instalados com uma breve descrição de cada um deles.

Para este artigo utilizaremos o liquidcrudextsolution.

Vamos então explorar os parâmetros esperados para este template através do comando abaixo:

dotnet new liquidcrudextsolution -h

Será apresentada a seguinte tela:

Para este template são esperados os seguintes parâmetros:

Parâmetro	Descrição
projectName	Namespace da Solution
entityName	Nome da Entidade
entityIdType	Tipo do Id da Entidade

Para começar o processo de criação do micro serviço, vamos criar um diretório chamado "catalogo" e vamos entrar no diretorio.

mkdir catalogo
cd catalogo

Realizando SETUP do Projeto

Neste exemplo o microserviço será chamado "Fructuoso.Exemplo.Catalogo", minha entidade será Produto e o tipo do Id será Guid.

dotnet new liquidcrudextsolution -p Fructuoso.Exemplo.Catalogo -e Produto -en Guid

Após executar o comando acima, a seguinte estrutura de pastas será criada:

📦src
 ┣ 📂Fructuoso.Exemplo.Catalogo.Domain
 ┃ ┣ 📂Entities
 ┃ ┃ ┗ 📜ProdutoEntity.cs
 ┃ ┣ 📜Fructuoso.Exemplo.Catalogo.Domain.csproj
 ┃ ┗ 📜IDomainInjection.cs
 ┣ 📂Fructuoso.Exemplo.Catalogo.WebApi
 ┃ ┣ 📂Controllers
 ┃ ┃ ┗ 📜ProdutoController.cs
 ┃ ┣ 📜Fructuoso.Exemplo.Catalogo.WebApi.csproj
 ┃ ┣ 📜Program.cs
 ┃ ┣ 📜Startup.cs
 ┃ ┗ 📜appsettings.json
 ┗ 📜Fructuoso.Exemplo.Catalogo.Microservice.sln

Antes de seguir, é necessário restaurar as dependêcias da solução. (Em alguns casos sua IDE pode sugerir fazer isso automáticamente para você)

cd src
dotnet restore

Conhecendo a estrutura da solução

O template escolhido criará automaticamente dois projetos WebAPI e Domain.

WebAPI

Neste projeto ficam os controllers e toda a injeção de dependência necessaria, sendo que parte dela já foi criada automaticamente pelo template do Liquid.

Domain

Neste projeto fica toda a regra de negócio necessária para o funcionamento do micro serviço, como estamos utilizando o Liquid CRUD Extension, a regra necessária para a criação de um CRUD básico fica totalmente encapsulada.

Nos próximos artigos veremos como estender esses comportamentos.

Implementação

Depois de explorar um poouco o código gerado automaticamente pelo template é possivel notar que temos 2 TODO para implementar e com a implementação desses dois blocos de código teremos nosso CRUD 100% funcional.

Entidade (ProdutoEntity)

Neste primeiro TODO precisamos apenas definir quais propriedades serão utilizadas.

Para este exemplo vamos criar apenas Código, Nome e Preço.

public class ProdutoEntity : LiquidEntity<Guid>
{
    public int Codigo { get; set; }
    public string Nome { get; set; }
    public double Preco { get; set; }
}

Startup

A classe Startup.cs é responsável pela configuração da nossa WebAPI, seguiremos com o passo a passo sugerido pelo TODO gerado pelo template. Neste artigo faremos uso do InMemory do Entity Framework.

Vamos criar o projeto Repository

dotnet new liquiddbcontextproject --projectName Fructuoso.Exemplo.Catalogo --entityName Produto

Adicione o projeto Repository na solução.

dotnet sln add Fructuoso.Exemplo.Catalogo.Repository/Fructuoso.Exemplo.Catalogo.Repository.csproj

Restaure as dependências do projeto novamente

dotnet restore

Adicione o projeto Repository como referência ao projeto WebAPI

cd Fructuoso.Exemplo.Catalogo.WebApi 
dotnet add reference ../Fructuoso.Exemplo.Catalogo.Repository/Fructuoso.Exemplo.Catalogo.Repository.csproj

Adicione o pacote Microsoft.EntityFrameworkCore.InMemory

dotnet add package Microsoft.EntityFrameworkCore.InMemory --version 5.0.13

Importe a referência do EntityFrameworkCore nesta classe

using Microsoft.EntityFrameworkCore;

Configure o DbContextOptions incluíndo o seguinte código abaixo do TODO (este passo determina o banco de dados que será utilizado pela aplicação)

Action<DbContextOptionsBuilder> options = (opt) => opt.UseInMemoryDatabase("CRUD");

Adicione o pacote Liquid.Repository.EntityFramework

dotnet add package Liquid.Repository.EntityFramework --version 2.*

Importe a referência do Liquid.Repository.EntityFramework.Extensions

using Liquid.Repository.EntityFramework.Extensions;

Importe a referência do Repository nesta classe

using Fructuoso.Exemplo.Catalogo.Repository;

Registre o DbContext no ServiceCollection

services.AddLiquidEntityFramework<LiquidDbContext, ProdutoEntity, Guid>(options);

Executando aplicação

Com o CRUD completamente implementado é hora de executar

dotnet run

Por padrão a aplicação rodará nas portas 5000 (http) e 5001 (https), ao acessar o endereço https://localhost:5001/swagger

Deverá ser apresentada uma tela como esta:

Encerramento

Como foi possível perceber, para criar um CRUD foi preciso apenas determinar as propriedades da nossa entidade e definir qual o repositório que será utilizado todo o restante do trabalho foi gerado automaticamente.

Por hoje é isso, se você curtiu esse artigo não esqueça de deixar seu like e fique ligado nos proximos posts com mais conteudo sobre o Liquid Framework.

Melhorando o tratamento de exceções no C#

Víctor Fructuoso — Thu, 02 Dec 2021 14:50:22 +0000

Um dos meus principais lemas como programador é:

Se você precisar debugar o código para achar um BUG, é por que o código não está bem escrito.

Neste artigo, abordo três formas de relançar uma exceção e quais as principais diferências entre elas.

Antes de falar sobre a Exception em si, precisamos entender a propriedade mais importante que ela tem... (pausa dramática)

StackTrace

Esta certamente é a propriedade mais importante de qualquer Exception, pois através dela é possível entender toda a "pilha de chamadas" que foi realizada, até o exato ponto onde a exceção foi lançada.

Daí chegamos ao ponto que muitos programadores iniciantes costumam errar...

É muito comum ver tratamentos de erro com algo mais ou menos assim:

_logger.LogError(ex.Message);

Quando isso é feito, estamos jogando fora praticamente toda e qualquer informação que pode nos ajudar a rastrear o erro através do Log.

Neste caso, o ideal seria utilizar algo como o código abaixo:

_logger.LogError(ex, ex.Message);

Neste link temos a documentação oficial da Microsoft com todas as implementações do método de extensão LogError da interface ILogger.

Caso você precise obter os dados da exceção para usar em algum outro local, é preferível ainda usar o ToString(), que entrega o Message concatenado com o StackTrace, fornecendo assim, um detalhamento completo do erro.

O cenário

Para ilustrar as três formas que serão abordadas, vamos entender o seguinte cenário:

A ClasseB possuí o método "OutroMetodo" não implementado.
A ClasseA possui o método "UmMetodo" que chama o método da ClasseB, que por sua vez lançará a exceção "NotImplementedException".

Veremos as três formas de implementar o tratamento de exceção na ClasseA, e o impacto de cada uma delas no Log da aplicação.

throw

Neste caso, a exceção é relançada mantendo o StackTrace completo.

Resultado:

System.NotImplementedException: The method or operation is not implemented.
   at ClasseB.OutroMetodo() in Program.cs:line 23
   at ClasseA.UmMetodo() in Program.cs:line 12
   at Program.<Main>$(String[] args) in Program.cs:line 3

throw ex

Nesta situação a exceção é relançada, mas diferentemente do cenário anterior o StackTrace do que aconteceu antes deste relançamento é descartado.

Em alguns casos isso pode ser útil, para que possamos ocultar algum detalhe do componente ou até mesmo tornar o log menor e mais objetivo.

Notem que neste caso, nenhuma referência a ClasseB é feita.

Resultado:

System.NotImplementedException: The method or operation is not implemented.
   at ClasseA.UmMetodo() in Program.cs:line 17
   at Program.<Main>$(String[] args) in Program.cs:line 3

CustomException

Neste caso é criado um tipo de exceção customizado, este novo tipo é lançado, passando a exceção original como InnerException.

Desta forma o StackTrace é dividido em dois, tornando mais claro o que aconteceu.

Resultado:

CustomException: Esta é uma exceçao customizada!
 ---> System.NotImplementedException: The method or operation is not implemented.
   at ClasseB.OutroMetodo() in Program.cs:line 23
   at ClasseA.UmMetodo() in Program.cs:line 12
   --- End of inner exception stack trace ---
   at ClasseA.UmMetodo() in Program.cs:line 17
   at Program.<Main>$(String[] args) in Program.cs:line 3

Conclusão

Não existe método certo ou método errado, o importante é entender o funcionamento de cada forma de trabalho, para que o detalhamento da exceção seja apresentada da melhor forma possível. Isso fará toda a diferença no momento de identificar um bug, inclusive aquele que você não consegue reproduzir na sua máquina.

A gambiarra de hoje pode ser o Design Pattern de amanhã!?

Víctor Fructuoso — Tue, 09 Nov 2021 22:37:35 +0000

Escrito em 1994, por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. O livro "Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos" tinha como principal objetivo catalogar 23 dos padrões mais populares na época.

Atualmente algumas pessoas conhecem o livro como "Gang Of Four", por conta de seus autores, sem contar que é uma referência muito mais simples de ser feita do que o próprio nome do livro.

No livro, os padrões são segregados em três categorias:

NOTA: O objetivo deste artigo não é falar sobre os padrões, caso você não os conheça recomendo o site refactoring.guru, que possui também uma versão em português.

Por definição, um padrão de projetos é uma solução vastamente utilizada para resolver um problema em comum, mas não necessariamente igual. É importante lembrar que, a implementação se torna mais simples ou mais complexa dependendo da linguagem em que ela está sendo implementada, no livro citado acima os padrões foram implementados em Smalltalk e C++.

O que atualmente conhecemos como um padrão de projeto, não nasceu um "padrão". Ele se tornou um padrão com o tempo, pois seu uso se demonstrou eficiente para resolver um problema "comum".

Tais implementações são criadas basicamente, para contornar uma limitação tecnológica e possivelmente se tornará obsoleta com a evolução das linguagens de programação, como por exemplo:

O STRAREGY atualmente pode ser implementado usando uma arrow function.
O SINGLETON pode ser completamente abstraído através dos nossos frameworks de injeção de dependências.

Outros padrões acabam evoluindo, como por exemplo o MVC, que apesar de ser um pattern, é amplamente conhecido por seus frameworks que estão presentes em praticamente todas as linguagens utilizadas atualmente.

Quando você encontrar um problema onde não existe uma solução pronta na internet, lembre-se a solução pode vir a virar um padrão, afinal de contas, quem nunca pegou uma solução de um problema de um projeto e copiou para um projeto novo?

Podemos dizer então dizer que...

Um padrão de projetos é uma gambiarra que "viralizou"?

Qual a sua opinião sobre isso? Manda ai nos comentários!!!

Aproveite para me seguir no Instagram, YouTube e LinkedIn

Otimizando os testes de uma aplicação .NET em mais de 90%

Víctor Fructuoso — Mon, 25 Oct 2021 16:47:59 +0000

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

Qual a diferença entre ClassFixture e CollectionFixture?

Para entendermos a diferença 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 três).

Entender o ciclo de vida dele pode impactar significante o tempo de execução dos seus testes, neste artigo veremos um cenário onde conseguimos reduzir o tempo de execução em mais de 90%.

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

Cada uma das duas classes (ClasseA e ClasseB) possuem dois cenários de testes (chamados apenas para fins de explicação de Teste1 e Teste2).

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

Desta forma teremos algo mais ou menos assim:

Sabendo disso é fácil associar que, para cada cenário de teste temos uma nova chamada ao construtor e um escopo totalmente isolado entre os cenários (que por padrão rodam em paralelo).

Onde é que entram as Fixtures então?

Imaginem que para um determinado conjunto de cenários 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. Porém 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 cenários de teste de uma mesma classe.

Já o CollectionFixture é utilizado sempre que queremos compartilhar os recursos com cenários de testes de classes distintas.

Imaginem que temos o seguinte cenário:

O FixtureX é um ClassFixture, enquanto o FixtureZ é um CollectionFixture, teríamos então algo mais ou menos assim:

Enquanto os recursos presentes na FixtureX são compartilhados apenas pelos cenários de teste de uma mesma classe. Os recursos presentes na FixtureZ serão compartilhados por TODOS os cenários de testes nas classes que estiverem associadas a ela.

Para recursos em que é necessário o isolamento e que apenas o próprio cenário de teste o recomendado é colocar o recurso na própria classe que implementa o cenário de teste.

Ao colocar o exemplo apresentado para rodar teremos algo mais ou menos assim (o resultado pode mudar de acordo com a execução, 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.Dispose
FixtureZ.Dispose

Entendido o que são e como funcionam as Fixture, vamos avaliar o seguinte cenário:

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 nós conseguimos levantar uma instância da nossa WebAPI em tempo de execução para que ela seja chamada via HTTP em nossos cenários de testes)

O comparativo foi feito utilizando a seguinte abordagem.

Em nossa API temos um método que recebe um objeto através de uma chamada POST, passa por todas as camadas da aplicação até chegar em um banco de dados utilizando Entity Framework InMemory.

A quantidade de cenários é representada pela execução do mesmo método passando entradas diferentes.

Então foram explorados dois cenários, o primeiro usando uma instância compartilhada entre os cenários através do conceito de Fixture, já o segundo foi implementado com uma instância dedicada gerada através do construtor da classe.

Ao simular algumas execuções chegamos aos seguintes cenários:

Quantidade	Instância Compartilhada	Instância Dedicada	%
1	1.4	1.3	-8%
5	1.4	2.1	33%
10	1.4	3.3	58%
100	1.4	16.9	92%

Como dito anteriormente as fixtures podem ser utilizadas para compartilhar recursos e estado, dependendo do cenário em que está sendo implementado pode gerar uma grande diferença de performance, porém em outros casos, o compartilhamento de recursos pode gerar efeitos colaterais no resultado dos testes, visto que os testes são executados ao mesmo tempo, logo se uma variável for modificada / consumida por mais de um teste ao mesmo tempo o resultado do teste pode variar a cada execução, ferindo assim um dos princípios básicos dos testes de unidade.

Espero que vocês tenham gostado do conteúdo, não deixem de deixar um like e me seguir para que não percam nenhum conteúdo.

Repositório GitHub

Os 3 principais frameworks de testes que todo desenvolvedor .NET deveria conhecer

Víctor Fructuoso — Tue, 19 Oct 2021 02:15:21 +0000

Todo bom desenvolvedor sabe a importância de testar seu código, o uso de testes automatizados nos permite acelerar esse processo onde conseguimos testar centenas, talvez milhares de cenários de testes distintos em questão de segundos.

Quando o assunto é .NET temos três grandes players brigando pela preferência dos desenvolvedores.

nUnit

nUnit é um framework de teste de unidade que foi baseado no JUnit, sua versão 3 (mais atual), foi completamente reescrita com diversas novas funcionalidades de suporte para diversas linguagens da plataforma .NET.

Versão Atual	3.13.2
Downloads	140.2M
Site	https://nunit.org/

MSTest

MSTest é o mais antigo da nossa lista, ele já foi o framework de teste padrão do Visual Studio (que atualmente conta com template de projeto de teste para todos os três frameworks da nossa lista)

Versão Atual	16.11.0
Downloads	252.3M
Site	https://github.com/microsoft/testfx

xUnit

O xUnit é o framework mais recente desta lista, foi desenvolvido pelo criador do nUnit v2 com o objetivo de simplificar e modernizar a forma como escrevemos testes.

Versão Atual	2.4.1
Downloads	166.4M
Site	https://github.com/xunit/xunit

Notem que apesar de mais novo o xUnit já supera o volume de downloads do nUnit

Principais Recursos

Abaixo uma relação com os principais recursos que os frameworks possuem:

[Test]	[TestMethod]	[Fact]	Define que o método representa um cenário de teste
[TestFixture]	[TestClass]	N/A	Marca uma determinada classe como sendo uma classe de testes. No xUnit essa identificação funciona a partir do método, todos os métodos marcados como testes através do atributo (Fact ou Theory) das classes publicas presentes no assembly são testados
Assert.That Record.Exception	[ExpectedException]	Assert.Throws Record.Exception	Enquanto o MSTest define a Exceção esperada através do atributo ExpectedException o nUnit e o xUnit trabalham de forma semelhante permitindo que um o código seja processado e exceção seja retornada em uma váriável permitindo testar não apenas o tipo da exceção, mas também suas propriedades.
[SetUp]	[TestInitialize]	Constructor	Método responsável por fazer o SetUp do cenário de teste. É válido lembrar que este método é executado antes de cada teste. Tanto o nUnit quanto o MSTest trabalham com atributos para identificar o método em questão, já o xUnit usa o construtor da classe para realizar este papel
[TearDown]	[TestCleanup]	IDisposable.Dispose	Método responsável por fazer o TearDown do cenário de teste. É válido lembrar que este método é executado ao final de cada teste. Tanto o nUnit quanto o MSTest trabalham com atributos para identificar o método em questão, já o xUnit usa o Dispose da classe para realizar este papel, para que funcione é preciso implementar a interface IDisposable
[OneTimeSetUp]	[ClassInitialize]	IClassFixture	Método responsável por fazer o SetUp da classe, ou seja este código é executado uma única vez para todos os testes contidos dento da classe em questão. Tanto o nUnit quanto o MSTest trabalham com atributos para identificar o método em questão, já o xUnit usa a interface IClassFixture, basta que a classe em questão implemente essa inteface (que não possui nenhum método) ela funciona apenas como marcação para que a Fixture implementada seja devidamente instanciada e passada para o construtor da classe. É valido lembrar que apenas uma instancia da Fixture será criada para aquela classe e TODOS os métodos presentes nela compartilharão a mesma instância.
[OneTimeTearDown]	[ClassCleanup]	IClassFixture	Método responsável por fazer o TearDown da classe, ou seja este código é executado uma única vez para todos os testes contidos dento da classe em questão. Tanto o nUnit quanto o MSTest trabalham com atributos para identificar o método em questão, já o xUnit usa a interface IClassFixture, neste caso a Fixture em questão implemente o método Dispose da interface IDisposable.
[Ignore("reason")]	[Ignore]	[Fact(Skip="reason")]	Utilizado para determinar que um determinado cenário de teste deve ser ignorado temporariamente
[Property]	[TestProperty]	[Trait]	Atributo utilizado para atribuir metadados aos cenários de testes que podem auxiliar no processo de organização dos mesmos (possiveis relatórios com resultados da execução dos testes)
[Theory]	[DataSource]	[Theory]	Utilizado para atribuir mais de uma entrada para um mesmo cenário de testes, por exemplo: Imaginem que precisamos testar um método responsável por validar uma formula matemática, porém nós queremos testar diversas entradas (inputs) com o uso desse recurso conseguimos realizar essa validação sem a necessidade de usar uma estrutura de loop (for / while).

Assertions (Verificações)

Principais formas de verificar se um cenário de teste está de acordo com o esperado.

nUnit	MSTest	xUnit	Comentários
Is.EqualTo	AreEqual	Equal	Verifica se dois objetos são iguais (EqualTo)
Is.Not.EqualTo	AreNotEqual	NotEqual	Verifica dois objetos são diferentes
Is.Not.SameAs	AreNotSame	NotSame	Verifica dois objetos são instancias diferentes.
Is.SameAs	AreSame	Same	Verifica se dois objetos são mesma instância.
Does.Contain	Contains	Contains	Verifica se um objeto está contido em uma colecão, se aplica também para strings (sub-string).
Does.Not.Contain	DoesNotContain	DoesNotContain	Verifica se um objeto NÃO está contido em uma colecão, se aplica também para strings (sub-string).
Throws.Nothing	N/A	N/A	Presente apenas no nUnit é utilizado juntamente com o Assert.That para garantir que uma determinada exceção não foi levantada.
N/A	Fail	N/A	Presente apenas no MSTest serve para fazer um teste falhar arbitrariamente utilizado em cenários em que a regra de validação é aplicada utilizando "IFs" Para o nUnit e xUnit a alternativa é trabalhar com Is.True(nUnit) e True(xUnit)
Is.GreaterThan	N/A	N/A	Presente apenas no nUnit serve para validar se o resultado é maior que um determinado valor. Para o MSTest e xUnit a alternativa é trabalhar com IsTrue (MSTest) e True (xUnit)
Is.InRange	N/A	InRange	Presente apenas no nUnit e no xUnit serve para validar se um objeto está dentro de um intervalo pré-definido, funciona para qualquer tipo que implementa a interface IComparable
Is.AssignableFrom	N/A	IsAssignableFrom	Presente apenas no nUnit e no xUnit serve para validar se um objeto é de um tipo pré-definido (ou derivado)
Is.Empty	N/A	Empty	Presente apenas no nUnit e no xUnit serve para validar se uma coleção está vazia.
Is.False	IsFalse	False	Verifica se uma determinada operação retorna false.
Is.InstanceOf	IsInstanceOfType	IsType	Diferentemente do AssignableFrom o InstanceOf verifica se um objeto é um determinado tipo, mas neste caso não considera derivados.
Is.NaN	N/A	N/A	Presente apenas no nUnit é utilizado em conjunto com o Assert.That para determinar se um objeto é um número.
Is.Not.AssignableFrom	N/A	N/A	Presente apenas no nUnit representa o cenário oposto do AssignableFrom verificando se um objeto não é de um determinado tipo ou derivado.
Is.Not.Empty	N/A	NotEmpty	Presente apenas no nUnit e xUnit verifica se uma coleção possui pelo menos um elemento.
Is.Not.InstanceOf	IsNotInstanceOfType	IsNotType	Representa o cenário oposto do InstanceOf verifica se um objeto não é de um tipo e não considera seus derivados.
Is.Not.Null	IsNotNull	NotNull	Verifica se um objeto é diferente de null.
Is.Null	IsNull	Null	Verifica se um objeto é null.
Is.True	IsTrue	True	Verifica se uma operação retorna true.
Is.LessThan	N/A	N/A	Presente apenas no nUnit serve para validar se um objeto é menor que um determinado valor. Funciona para qualquer tipo de objeto que implementa a interface IComparable Para o MSTest e xUnit a alternativa é trabalhar com IsTrue (MSTest) e True (xUnit)
Is.Not.InRange	N/A	NotInRange	Presente apenas no nUnit e no xUnit serve para validar se um objeto está fora de um intervalo pré-definido, funciona para qualquer tipo de objeto que implementa a interface IComparable
Throws.TypeOf	n/a	Throws	Verifica se uma determinada operação lança uma exceção pré-definida.

Se você curtiu o post, deixe o seu coração e compartilhe com seus amigos.

Aproveite para me seguir aqui, no YouTube e no Instagram. Os links estão na BIO.

Em breve lançarei uma série de vídeos demonstrando uma mesma aplicação sendo testado pelos três frameworks. Fiquem ligados para não perder nenhum detalhe.

Qual a diferença entre um MOCK e um STUB?

Víctor Fructuoso — Thu, 14 Oct 2021 01:02:46 +0000

Recentemente me mandaram a seguinte pergunta: "Qual a diferença entre stub e mock?"

Quando falamos sobre as estratégias utilizadas para testar um código possuímos os seguintes conceitos.

Fake

O Fake representa uma implementação real mas não necessariamente igual a que será utilizada em ambiente produtivo, como por exemplo um repositório persistido em memória;

Obs.: O Fake é uma técnica utilizada em casos de testes integrados, onde nós testamos mais de uma camada em um único cenário de testes.

Vejam o exemplo abaixo:

Estamos criando uma classe concreta chamada ProdutoRepositoryFake que efetivamente implementa a interface IProdutoRepository, porém de uma forma simplificada, e potencialmente diferente da que será publicada em produção.

Spy

Spies são utilizados em casos onde queremos validar o comportamento de um método e sua interação com suas dependências, neste caso as dependências não são modificadas;

Obs.: O Spy é uma técnica utilizada em casos de testes Integrados, onde nós testamos mais de uma camada em um único cenário de testes.

Vejam o exemplo abaixo:

Estamos aplicando um Spy no nosso ProdutoRepositoryFake (pois nesse código de exemplo é a unica classe concreta que deriva de IProdutoRepository que nós temos), este mesmo exemplo poderia ser aplicado com qualquer classe concreta.

Neste exemplo foi preciso usar a interface IProdutoRepository e a classe ProdutoRepositoryFake como base para isso (linha 4).

Por que o código da linha 3 não funciona? Não funciona porque os métodos em questão não possuem o modificador "virtual", ou seja, ele não pode ser sobrescrito.

Stub

Stub é uma implementação que nos permite fornecer respostas prontas, são utilizados para cenários onde queremos validar apenas o resultado;

Vejam o exemplo abaixo:

Estamos criando um stub de um IProdutoRepository onde sempre que o método Obter for chamado passando o parâmetro id igual a 1, ele deve retornar um Produto { Id = 1, Nome = "TECLADO" }

Obs.: Está sendo utilizado um framework para simplificar a implementação do Stub, em um cenário natural, seria necessário criar um ProdutoRepositoryStub que imlpementasse a interface IProdutoRepository, o que seria muito mais verboso.

Mock

Diferentemente do Stub, o mock possui a capacidade de validar o comportamento da implementação, validando por exemplo quantas vezes um determinado método foi chamado, quais foram os parâmetros passados dentre outras informações, ou seja, o mock possui a capacidade do Spy e do Stub juntas.

Vejam o exemplo abaixo:

Estamos criando uma instancia do IProdutoRepository utilizando um Mock, sendo assim nós conseguimos definir arbitrariamente o retorno para os métodos que esta interface possui.

Além disso nós conseguimos também validar posteriormente se um determinado método foi chamado, com quais parametros foi chamado e quantas vezes ele foi chamado.

Dummy

Um objeto dummy é um objeto que nós utilizamos apenas para viabilizar a execução do nosso código, mas que para o nosso teste ele não será utilizado em momento algum.

Vejam o exemplo abaixo:

Estamos criando um método auxiliar que produz um Produto válido. Para o escopo do nosso teste é irrelevante conhecer as características de um produto válido, os valores atribuídos nas propriedades deste objeto também são irrelevantes.

Imagine um cenário onde temos dezenas de testes que precisam receber um Produto válido, eis que uma nova regra de validação é criada.

Automaticamente TODOS os testes que dependem de um Produto válido começarão a falhar (o que é bom), se não fosse pelo Dummy seria necessário modificar todos os testes um a um.

Considerações Finais

Segue o repositório no GitHub com os exemplos utilizados link

É válido lembrar que para estes exemplos estou usando o Moq que reduz significantemente a complexidade de escrever um duble de código.

Agora, mesmo que você prefira continuar falando que vai mocar tudo, você entende e sabe a diferença de cada uma dessas técnicas.

Se você gostou aproveite para deixar o seu Like e me seguir aqui e nas outras redes link

Referências

Mocks Aren't Stubs

7 passos para construir uma P.o.C. LIKE A BOSS

Víctor Fructuoso — Sun, 03 Oct 2021 13:09:14 +0000

7 passos para construir uma P.o.C. LIKE A BOSS

Todos nós já nos deparamos com situações em que precisamos desenvolver algo novo, ou que possui requisitos peculiares e não temos uma solução "pronta".

Em alguns casos desenvolver, ou tentar desenvolver, a solução completa pode demandar tempo e/ou dinheiro (normalmente uma coisa leva a outra).

Uma das alternativas para evitar um grande investimento quando não há um nível aceitável de segurança no caminho que está sendo seguido, é realizar pequenos experimentos. Afinal de contas se algo der errado, o prejuízo será muito menor e haverá tempo para pensar em outras alternativas.

No desenvolvimento de software esses experimentos são chamados de POC (Proof Of Concept), ou "Prova de Conceito".

1. Requisitos

A primeira etapa do processo é entender quais são nossos requisitos e restrições, pois todo o trabalho será realizado com objetivo de validar o quão aderente a eles o experimento é.

Nesta etapa vamos também dividir nossos requisitos em essenciais e desejáveis. Esta segregação ajudará em todo o processo. Pensem comigo:

Faz sentido continuar investindo tempo e dinheiro em um estudo em que nós já sabemos que não atenderá nossos requisitos essenciais?

2. Estabeleça Critérios (métricas)

Uma vez que os requisitos da prova de conceito estão claros é necessário estabelecer quais os critérios que serão utilizados para evidenciar se a solução desenvolvida atende ou não aos requisitos estabelecidos inicialmente, esses critérios devem ser tangíveis, ou seja, nossas respostas para estes critérios não podem ser subjetivas.

3. Delimite o Escopo

Nesta etapa será definido o que efetivamente será implementado na prova de conceito, lembrando sempre que o principal objetivo da prova de conceito é poupar tempo e dinheiro, logo, o esforço para a construção da mesma deve ser significantemente menor que o esforço para construir a solução definitiva.

4. Plano de Ação

Com o escopo estabelecido é preciso elaborar um plano de ação indicando como o escopo será atendido e quanto tempo será investido para validar a teoria, ou seja, precisamos identificar as etapas que precisam ser realizadas e o esforço estimado para a conclusão de cada uma delas.

5. Hands-On (Implementação)

Durante a implementação efetiva da POC precisamos ter em mente que:

Este código deve ser funcional, porém ele é apenas um experimento;
Apesar de não possuir as mesmas restrições de qualidade que um código "normal", o código precisa estar legível para que possa ser analisado e potencialmente reutilizado em uma implementação definitiva;
Seus esforços devem SEMPRE estar 100% direcionados para responder às perguntas estabelecidas anteriormente.

6. Documente

Com a prova de conceito devidamente implementada é hora de voltar às métricas e validar o quanto a solução construída é aderente aos requisitos e restrições definidos no primeiro passo.

Nesse momento os requisitos que já estavam divididos em (essenciais e desejáveis) agora passam a ser sub-divididos também em (simples e complexos) para implementar de forma definitiva.

É recomendável documentar os resultados encontrados para apresentar aos stakeholders e manter o histórico do porque tal decisão foi tomada.

NOTA: Pode ser necessário testar outras abordagens e comparar os resultados até que se chegue em um resultado satisfatório.

7. Road Map

Ao chegar nessa etapa temos nossa prova de conceito efetivamente pronta para ser desenvolvida para se tornar um entregável.