Testar métodos do repositório apenas em testes de integração
Riderman Sousa
Esta dúvida é originada de outro post aqui mesmo no .Net Architects. Resolvi criar outra thread com foco apenas nesta questão.
Publiquei também no meu twitter sobre como/onde testar métodos do repositório.
Vamos a seguinte situação: Eu tenho uma interface IRepository como esta:
public interface IRepository<T>
where T: class, IEntity
{
IQueryable<T> Query(Expression<Func<T, bool>> expression);
// ... Omitido
}E uma implementação genérica do meu IRepository
public class Repository<T> : IRepository<T>
where T : class, IEntity
{
public IQueryable<T> Query(Expression<Func<T, bool>> expression)
{
return All().Where(expression).AsQueryable();
}
}Esta é uma implementação base e pode ser usada por qualquer repositório. Ela contém a implementação básica do meu ORM.
Alguns repositórios tem filtros específicos, neste caso teremos o IEmployeeRepository com um filtro específico:
public interface IEmployeeRepository : IRepository<Employee>
{
IQueryable<Employee> GetInactiveEmployees();
}E a implementação da interface IEmployeeRepository:
public class EmployeeRepository : Repository<Employee>, IEmployeeRepository // TODO: I have a dependency with ORM at this point in Repository<Employee>. How to solve? How to test the GetInactiveEmployees method
{
public IQueryable<Employee> GetInactiveEmployees()
{
return Query(p => p.Status != StatusEmployeeEnum.Active || p.StartDate < DateTime.Now);
}
}Dúvidas
É corretor herdar de
Repository<Employee>?
O objetivo é reaproveitar código uma vez que toda a implementação deIRepositoryjá foi feita. SeEmployeeRepositoryherdar apenas deIEmployeeRepository, terei de literalmente copiar e colar o código deRepository<T>.Neste nosso exemplo, em
EmployeeRepository : Repository<Employee>o nossoRepositoryse encontra em nossa camada ORM. Ou seja, temos uma dependência aqui com o nosso ORM impossibilitando de realizar algum teste unitário.Como criar um teste unitário para garantir que o filtro
GetInactiveEmployeesretorne todos os Employees em que o Status != Active e StartDate < Data atual. Não posso criar um Fake/Mock deIEmployeeRepositoryporque o que eu estaria testando? Preciso testar a implementação real deGetInactiveEmployees.
O código completo encontra-se no Github
Web Developer | MCPD Certify
Skype.: 4042-6002 | Cel.: (31) 8681-1986
bindsolution.comMicrosoft Parner Network
edmilson hora
neste caso testar a implementação real do repositório não é mais teste unitário passa a ser teste integrado.
O teste unitário, neste caso, testaria se o repositório esta sendo chamado corretamente e então haveria uma implementação fake ou mock para responder se ele foi chamado.
Para verificar, se sua logica de filtro esta correta (teste unitário), eu só penso em um jeito, dados fake numa classe local, onde a logica fosse aplicada, para ver se retorna foi o esperado.
De: Riderman Sousa <rider...@bindsolution.com>
Para: dotnetar...@googlegroups.com
Enviadas: Terça-feira, 11 de Junho de 2013 9:10
Assunto: [dotnetarchitects] Testar métodos do repositório apenas em testes de integração
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
---
Você está recebendo esta mensagem porque se inscreveu no grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para dotnetarchitec...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
Riderman Sousa
Riderman Sousa
Edmilson, esqueci de comentar mas não tenho como chamar EmployeeRepository.Store(obj) porque no meu projeto de testes unitários não existe uma referência ao ORM.
Store fica em no repositório genérico Repository<T> com uma referência ao NHibernate.
Juan Lopes
seu caso o método All()) para testar somente a implementação de
GetInactiveEmployees.
Explicando melhor: o que você precisa, na verdade é testar se o
predicado definido em GetInactiveEmployees faz sentido com o seu
negócio (se ele vai ser traduzido para uma query válida no seu banco é
outro teste). Por isso, se você puder capturar as operações em cima do
seu queryable, você poder repetí-las, digamos, usando um
List<Employee> e ver se isso faz sentido.
Uma forma fácil de fazer isso é injetar o IQueryable<Employee> que
representa o All no construtor do repositório. IQueryables são
imutáveis por contrato, então basta você ter uma instância. No teste
você pode simplesmente injetar um mock Queryable que só captura as
chamadas a ele. Tem um exemplo (incompleto) no meu github [1], que
mostra o menor IQueryable possível (com seu respectivo
IQueryProvider).
[1] https://github.com/juanplopes/simple-commons/blob/master/src/Simple/Expressions/EmptyQueryable.cs
--
https://github.com/juanplopes
Riderman Sousa
edmilson hora
Assunto: Re: [dotnetarchitects] Testar métodos do repositório apenas em testes de integração
Juan Lopes
você tentar insinuar que existe qualquer tipo de independência entre o
contrato de um repositório (IRepository<Employee>), sua implementação
de acordo com o domínio (EmployeeRepository) e a implementação de
infra (Repository<Employee>). Todos eles estão fortemente acoplados
pela herança de EmployeeRepository.
Além do mais, esse seu repositório não é bem um repositório de
verdade. Ele parece muito com uma mistura entre um DAO (por essa
tentativa de modelar todas as operações necessárias para todas as
entidades) com um Specification (por retornar IQueryable<T> nas
consultas).
Esse problema de design é que faz com que seus testes sejam custosos.
E eles estão gritando justamente isso. Você não vai conseguir testar
isoladamente com esse acoplamento todo.
--
https://github.com/juanplopes
Francisco Berrocal
Att,