André Borges

Pessoal,

Recentemente falei sobre injeção de dependência (Veja: Parte 1 e Parte 2), de modo a minimizarmos o acoplamento nas nossas aplicações, onde usamos o Ninject como container de Inversão de Controle (IoC – Inversion of Control) e aproveitamos para apresentar o NuGet.

Também falei recentemente sobre o NBuilder, que nos ajuda a criar objetos fake, para usarmos nos nossos testes de unidade.

A idéia agora é mostrar como criar stub’s para utilizarmos nos nossos testes de unidade. Para isso, usamos algum framework de isolamento (Moq, NMock, Rhino Mocks, TypeMock, etc…). Para quem não sabe o que é um stub, ou acha que stub e mock é tudo a mesma coisa, recomendo fortemente a leitura do artigo: Mocks não são Stubs, do Martin Fowler.

Mas porque precisamos de um stub?
Dizemos que um teste não é um teste de unidade se:

• Ele se conecta a um banco de dados;
• Ele se comunica pela rede;
• Ele “toca” o sistema de arquivos;
• Ele não pode rodar junto com algum outro dos seus testes de unidade.

Assim, na prática, usamos mock‘s e stub‘s para “simular” acesso a bancos de dados, comunicação via rede, acesso ao sistemas arquivos, etc… Com isso, dizemos que estamos isolando o sistema que está sendo testado.

Vamos ao código?
Como sempre, vamos direto ao assunto, normalmente é mais fácil de entender a idéia. Vamos utilizar o mesmo exemplo dos post’s citados acima:

Interface:

public Interface ICategoryRepository
{
   IList GetAll();
}

Repositório “verdadeiro”:

public class CategoryRepository : ICategoryRepository
{
   public IList GetAll()
   {
      DataContext ctx = new DataContext();
      return ctx.Categories;
   }
}

Repositório “fake”:

public class CategoryRepositoryFake : ICategoryRepository
{
   public IList GetAll()
   {
      var category1 = new Category() { Id = 1, Name = "Cat 1" };
      var category2 = new Category() { Id = 2, Name = "Cat 2" };
      var category3 = new Category() { Id = 3, Name = "Cat 3" };

      return new List() { category1, category2, category3 };
   }
}

Controller:

public class CategoryController : Controller
{
   [Inject]
   public ICategoryRepository Repository { get; set; }

   public ActionResult Index()
   {
      var categories = this.Repository.GetAll();

      return View(categories);
   }
}

A nossa motivação agora é eliminar a classe “CategoryRepositoryFake”. Para isso, utilizaremos o Moq que, dada uma interface (no nosso caso “ICategoryRepository”), ele nos “entrega” um objeto fake automaticamente. Na verdade, ele cria um objeto proxy, cuja finalidade é a de “fingir” ser um objeto “real”, para que um outro componente (ou objeto) possa “acreditar” que está falando com um objeto “real”. Basicamente, a mesma coisa que fizemos quando criamos manualmente o objeto fake… Só que o Moq faz isso de forma transparente e automática, e de quebra nos traz uma série de outros benefícios (coisa pra outro post, em breve).

Vamos ver como ficaria um teste de unidade da action “Index”, usando o Moq, NBuilder e o Ninject. Toda a “brincadeira” é feita na seção “Arrange” do teste:

[TestClass()]
public class CategoryControllerTest
{
   private IKernel kernel = new StandardKernel();

   [TestMethod()]
   public void Index_Returns_List_Of_Categories()
   {
      // Arrange
      // Cria o mock usando o Moq
      Mock<ICategoryRepository> categoryRepositoryMock
                                        = new Mock<ICategoryRepository>();

      // Cria dados "fake" com o NBuilder
      IEnumerable<Category> categoriesList
                         = Builder<Category>.CreateListOfSize(10).Build();

      // Faz o setup do mock usad pelo SUT, para retornar os dados
      // criados com o NBuilder. Acabamos de criar um STUB.
      categoryRepositoryMock
                          .Setup(m => m.GetAll()).Returns(categoriesList);

      // Informamos ao Ninject: Quando alguém precisar de um
      // ICategoryRepository, entregue o objeto criado pelo mock
      kernel.Bind<ICategoryRepository>()
                            .ToMethod(m => categoryRepositoryMock.Object);

      // Act
      CategoryController sut = kernel.Get<CategoryController>();
      ViewResult viewResult = sut.Index();

      // Assert
      IEnumerable<Category> viewData
                     = viewResult.ViewData.Model as IEnumerable<Category>;

      Assert.IsNotNull(viewData);
      Assert.AreEqual(10, viewData.Count());
   }
}

Algumas observações:
Nas linhas 11 e 12, estamos efetivamente criando o nosso objeto mock, baseado na interface “ICategoryRepository”.

Nas linhas 20 e 21, estamos configurando o mock para que, quando alguém invocar o método “GetAll()” do mock, “forçamos” o retorno de uma lista de objetos criada anteriormente, em memória. Acabamos de definir o “tal” stub.

Outro ponto importante está na linha 26. Repare que estamos adicionando ao Ninject uma referência para a interface “ICategoryRepository” apontando para a propriedade “Object” do nosso mock. A propriedade “Object” nos retorna o objeto proxy que comentei anteriormente, e que implementa a interface “ICategoryRepository”.

O que acharam? Nesse post, vimos como criar stub‘s. No próximo, vamos criar mock‘s.

Forte abraço.

Pessoal,

Recentemente descobri (não sei se vocês já conheciam) uma ferramenta bem interessante, que tem ajudado bastante na criação de stub‘s para os testes de unidade. Trata-se do NBuilder (http://nbuilder.org).

O NBuilder é um projeto open source, que permite criar objetos a partir das suas classes muito rapidamente, através de uma interface fluente e extensível. Ele instancia os objetos e atribui automaticamente valores às propriedades e campos públicos da sua classe, além de permitir que você substitua os valores das propriedades dos objetos criados usando expressões lambda.

Bom, como sempre, vamos aos exemplos práticos que sempre são mais elucidativos que a teoria. Acredito que rapidamente vocês vão entender a “mão na roda” que essa ferramenta é. Para que você possa reproduzir esses exemplos, basta fazer o download do NBuilder e referenciá-lo no seu projeto.

Tomando como exemplo esse domínio:

public class Blog : IBusinessEntity
{
   public int Id { get; set; }
   public string Name { get; set; }
   public IList Posts { get; set; }
}

public class Post : IBusinessEntity
{
   public int Id { get; set; }
   public string Title { get; set; }
   public string Text { get; set; }
   public string Author { get; set; }
}

Criei alguns testes de unidade para exemplificar a utilização do NBuilder:

[TestMethod]
public void Build_Blog()
{
	// Arrange

	// Act
	var blog = Builder<Blog>.CreateNew().Build();

	// Assert
	Assert.IsNotNull(blog);
	Assert.AreEqual(1, blog.Id);
	Assert.AreEqual("Name1", blog.Name);
}

Perceberam o que o método Builder<Blog>.CreateNew() fez? Ele instanciou um objeto do tipo Blog e preencheu as propriedades Id e Name apropriadamente, e o método Build() nos retornou o objeto. Simples demais.

Podemos também criar listas de objetos muito facilmente:

[TestMethod]
public void Build_ListOfPosts()
{
	// Arrange

	// Act
	var posts = Builder<Post>.CreateListOfSize(10).Build();

	// Assert
	Assert.AreEqual(10, posts.Count);
	Assert.AreEqual(1, posts.First().Id);
	Assert.AreEqual(10, posts.Last().Id);
	Assert.AreEqual("Title1", posts.First().Title);
	Assert.AreEqual("Title10", posts.Last().Title);
	Assert.AreEqual("Text1", posts.First().Text);
	Assert.AreEqual("Text10", posts.Last().Text);
	Assert.AreEqual("Author1", posts.First().Author);
	Assert.AreEqual("Author10", posts.Last().Author);
}

Muito legal. O método Builder<Post>.CreateListOfSize(int) instanciou 10 objetos do tipo Post, preencheu as propriedades apropriadamente e os retornou em um IList<Post>:

• A propriedade Id (do tipo int), recebeu os valores 1, 2, …, 10;
• A propriedade Title (do tipo string), recebeu os valores “Title1”, “Title2”, …, “Title10”;
• A propriedade Author (do tipo string), recebeu os valores “Author1”, “Author2”, …, “Author10”.
• Etc…

No primeiro exemplo, a propriedade Posts (que é um IList<Post>) do objeto Blog não foi preenchida. Para que essa propriedade seja preenchida, precisamos usar o método With:

[TestMethod]
public void Build_ListOfBlogsWithPosts()
{
	// Arrange
	var posts = Builder<Post>.CreateListOfSize(10).Build();

	// Act
	var blog = Builder<Blog>.CreateNew()
                       .With(b => b.Posts = posts).Build();

	// Assert
	Assert.IsNotNull(blog);
	Assert.AreEqual(10, blog.Posts.Count);
	Assert.AreEqual(1, blog.Posts.First().Id);
	Assert.AreEqual(10, blog.Posts.Last().Id);
	Assert.AreEqual("Title1", blog.Posts.First().Title);
	Assert.AreEqual("Title10", blog.Posts.Last().Title);
}

Esses são exemplos bem simples, mas nos dá uma idéia do que podemos fazer com a ferramenta. Temos vários outros métodos, que nos permite:

• Definir valores para várias propriedades;
• Definir valores para construtores;
• Executar métodos da classe após instanciá-la;
• Setar propriedades para todos os itens de um IList;
• Obter itens randomicamente de listas;
• Navegar pelos itens de listas;
• Definir valores para propriedades do tipo DateTime com uma sintaxe fluente bem legal.

Bem, isso foi só uma amostra do que é possível fazer com o NBuilder, vale muito a pena dar uma olhada.

Em um próximo post vou mostrar algumas “coisas” um pouco mais complexas que já fiz com ele, além de mostrar como o tenho utilizado juntamente com o Moq (http://code.google.com/p/moq), para criação de stub‘s nos testes de unidade.

Forte abraço.