Testes de integração com NHibernate

[Riderman Sousa]

Bom dia Pessoal. Não sou muito de postar aqui até porque arquitetura não é o meu forte então se falar bobagem por favor me perdoem.

Estou criando um projeto de testes (testes de integração) para testar os mapeamentos, objetos de domínio e repositórios com o NHibernate.

Para facilitar, criei uma class base onde é feita a configuração do NHibernate:

[TestClass] public abstract class NHibernateDomainBaseTest
{
protected ISession Session { get; private set; }
protected static ISessionFactory SessionFactory {get; private set; }
private static Configuration _configuration;
[TestInitialize] public void SetUp()

{
_configuration = Fluently.Configure()
.Mappings(m =>
{
m.FluentMappings.AddFromAssemblyOf<UsuarioMap>().Conventions.AddFromAssemblyOf<EnumConvention>();
})
.ExposeConfiguration( c => new SchemaExport(c).Execute(false, true, false) )
.BuildConfiguration();
SessionFactory = _configuration.BuildSessionFactory();
Session = SessionFactory.OpenSession();
}
[TestCleanup] public void Cleanup()

{
Session.Close(); Session.Dispose();

}

}

Desta forma minhas classes de testes herdam da class base, exemplo: `ProcessoTest : NHibernateDomainBaseTest` Reparem que para cada TestMethod a base de dados é recriada e isto tem um impacto na performance e em outros fatores.

Lendo este artigo resolvi implantar testes por transação. Basicamente cada TestMethod excuta em uma transaction que nunca é comitada.

Gostaria de saber a opinião de vocês.

Como vocês trabalham testes de integração com base de dados? Como vocês fazem no NHibernate?

[David Anderson Lino de Sousa]

Pra diminuir o impacto dessa recriação de base, você pode usar um BD em memória.

Att,
David 

2013/5/20 Riderman Sousa <rider...@bindsolution.com>

--
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.
 
 

[David Anderson Lino de Sousa]

http://ayende.com/blog/3983/nhibernate-unit-testing
e
http://jason-mitchell.com/software-development/in-memory-database-using-fluent-nhibernate/

Talvez lhe ajudem.

Att,
David 

2013/5/20 David Anderson Lino de Sousa <david.and...@gmail.com>

[Riderman Sousa]

David, já tinha lido a respeito só que fiquei com um pé atrás em usar SQLite em memória por alguns motivos:

1. No LocalDb tenho o Manager Studio para verificar quais dados realmente estão no banco de dados
2. No Ambiente de dev já é utilizado o LocalDb como base de dados, seria interessante manter o mesmo nos projetos de integração. Até por causa de configuração, drivers etc...
3. No ambiente de produção, o que mais se aproxima do SQL Server 2008 (base de produção) é o LocalDb

Mas vou dar uma estudada.

Vlw.

[Mauricio Aniche]

Oi Riderman,

Tenho usado rollback mesmo ao final de cada teste. Isso geralmente
resolve a maioria dos problemas.

Não sou muito fã de bancos em memória. Apesar deles serem rápidos, já
tive problemas quando rodei no banco de produção. Não me lembro quais
problemas exatos, mas era algo relacionado com constraints e queries
malucas.

Um abraço,
--
Mauricio Aniche
www.TDDNoMundoReal.com.br
www.aniche.com.br
@mauricioaniche

2013/5/21 Riderman Sousa <rider...@bindsolution.com>:

[Riderman Sousa]

Mauricio, tenho a mesma opinião.

Fica estranho você falar em testes de integração quando sua base de teste é em memória e a de produção não.

Testes de integração devem aproximar ao máximo o ambiente de produção.

O principio diz que os testes devem ser isolados o máximo possível. 

Ou seja, um registro não pode afetar o resultado de um outro teste. Isto não significa uma base de dados para cada testes.

Além de tudo o Debug fica mais complicado, por exemplo para validar se o banco está sendo gerado com determinada estrutura (schema).

2013/5/23 Mauricio Aniche <maurici...@gmail.com>

Você recebeu esta mensagem porque está inscrito em um tópico do grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste tópico, acesse https://groups.google.com/d/topic/dotnetarchitects/LXP9FFQyp4Q/unsubscribe?hl=pt-BR.
Para cancelar a inscrição neste grupo e todos os seus tópicos, envie um e-mail para dotnetarchitec...@googlegroups.com.

[Rafael Ponte]

Olá,

Dar rollback no fim de cada teste é uma boa prática e evita muita dor de cabeça com sujeira no banco de dados, mas em alguns cenários não é possível dar rollback - como em transações independentes.

Vale salientar também um cuidado que deve-se ter em alguns testes com o (N)Hibernate, pois pode ocorrer de você ter um falso-positivo devido ao cache de primeiro nível - então algumas vezes você pode precisar executar um flush() ou clear() explicitamente.

2013/5/23 Riderman Sousa <rider...@bindsolution.com>

--
Rafael Ponte
http://www.triadworks.com.br

[Mauricio Aniche]

Sim, flush() e clear() devem ser usados com frequência!

Quando mais perto do mundo real, mais chato é o teste. Não tem jeito! :/

Mauricio Aniche
www.TDDNoMundoReal.com.br
www.aniche.com.br
@mauricioaniche

2013/5/23 Rafael Ponte <rpo...@gmail.com>: