Testabilidade na camada de dados usando Repositorio

[higor.cesar]

Fala pessoal, peço a opnião de vocês com o seguinte problema. Eu não
concordo com o modelo de testes difundido quando usamos o "padrão"(não
se é um padrão) repositorio de criar coleções em memória e realizar os
testes.Não consigo ver ROI em testes deste tipo. Por exemplo quando
temos uma implementação do repositorio usando SQL nós não rodamos o
SQL, sinto como se estivesse apenas assegurando que a interface da
camada de dados não será alterada.
Uma opção que vi é realizar testes usando transactions com uma base de
dados de testes por exemplo. Alguem ai faz isso?

[Juan Pedro A. Lopes]

Eu faço isso. Mas faço escondido, porque todo mundo critica. :P

Só precisa tomar cuidado pois se o seu método abrir uma transação explicitamente, você vai ter uma série de problemas. Quando se faz transação via AOP isso é mais fácil de lidar.

2010/6/1 higor.cesar <higo...@gmail.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

--
Kind regards,
Juan Lopes

[Pedro Reys]

Eu uso ambas as opções que o Higor apresentou, stubs para testes unitários e uma base local para testes integrados.

Pelo que vocês, Higor e Juan, disseram me parece que vocês estão fazendo testes de integração apenas, então?

Como testam o isoladamente o comportamento de um objeto que dependa de um repositório?

- Pedro Reys

2010/6/1 Juan Pedro A. Lopes <juanp...@gmail.com>

[higor.cesar]

Olá Pedro, eu falo de testes de unidade. O que fazemos é criar
coleções na memória e executar os métodos com estes dados, no entanto
quando temos uma implementação de repositorio em SQL quase nada é
realmente testado. Eu não tenho testes de integração, isso fica com
QA. A questão é: Vale a pena escrever testes contra a interface do
repositório com dados em memoria? se você entender o que estou falando
saberá que na verdade nenhum comportamento é testado pois o SQL não é
executado.

On 1 jun, 14:49, Pedro Reys <pedror...@gmail.com> wrote:
> Eu uso ambas as opções que o Higor apresentou, stubs para testes unitários e
> uma base local para testes integrados.
>
> Pelo que vocês, Higor e Juan, disseram me parece que vocês estão fazendo
> testes de integração apenas, então?
>
> Como testam o isoladamente o comportamento de um objeto que dependa de um
> repositório?
>
> - Pedro Reys
>

> 2010/6/1 Juan Pedro A. Lopes <juanplo...@gmail.com>

>
> > Eu faço isso. Mas faço escondido, porque todo mundo critica. :P
>
> > Só precisa tomar cuidado pois se o seu método abrir uma transação
> > explicitamente, você vai ter uma série de problemas. Quando se faz transação
> > via AOP isso é mais fácil de lidar.
>

> > 2010/6/1 higor.cesar <higor....@gmail.com>

>
> > Fala pessoal, peço a opnião de vocês com o seguinte problema. Eu não
> >> concordo com o modelo de testes difundido quando usamos o "padrão"(não
> >> se é um padrão) repositorio de criar coleções em memória e realizar os
> >> testes.Não consigo ver ROI em testes deste tipo. Por exemplo quando
> >> temos uma implementação do repositorio usando SQL nós não rodamos o
> >> SQL, sinto como se estivesse apenas assegurando que a interface da
> >> camada de dados não será alterada.
> >> Uma opção que vi é realizar testes usando transactions com uma base de
> >> dados de testes por exemplo. Alguem ai faz isso?
>
> >> --
> >> 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<dotnetarchitects%2Bunsu...@googlegroups.com>

> >> Para mais opções visite o grupo em
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > --
> > Kind regards,
> > Juan Lopes
>
> > --
> > 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<dotnetarchitects%2Bunsu...@googlegroups.com>

[Rodrigo Vieira]

Nossa empresa trabalha com um produto bem grande (estamos na versão
15.0), então esse lance de testes de integração é algo que quebramos
muito a cabeça.

A gente usa migrações para atualizar o banco, ou seja, toda vez que
alguém quer alterar ou criar algo no BD precisa criar um arquivo .sql
que contém os comandos necessários. Esses arquivos são criados de
forma sequencial, step1.sql, step2.sql etc, então nossos testes de
integração antes de mais nada criam um banco de dados vazio e rodam
todos esses steps. Aí sim que os testes de integração são rodados, em
cima desse bd temporário. Ao fim dos testes, a gente dá um drop nesse
bd.

Como dá pra imaginar, isso significa que esses testes de integração
rodam bem devagar (pode levar horas), a gente só executa eles1x por
dia, de madrugada, ao contrário dos testes unitários que rodam o tempo
todo em nosso servidor de CI.

Mas uma coisa que notamos desde que começamos a usar mais princípios
de DDD é que, quando bem feito, precisamos menos e menos de testes de
db e mais e mais testes unitários, ou seja, estamos reduzindo a
quantidade de regras de negócio embutidas em queries SQL, e
trazendo-as pro código C#.

Pra quem usa NHibernate a coisa parece ser mais fácil, ele tem como
gerar esse bd temporário (ou mesmo em memória, usando sqlite3), mas
não é nosso caso.

Abs

Rodrigo

2010/6/1 higor.cesar <higo...@gmail.com>:

[Rodrigo Vieira]

P.S. Esqueci de mencionar, mas ao invés de rodas esse monte de
arquivos .sql tb tem gente que dá um attach num arquivo .mdf, pode ser
mais prático.

2010/6/1 Rodrigo Vieira <rodr...@gmail.com>:

[Guilherme Oenning]

Se seu teste não testa nada, então não faz sentido tê-lo. O que me parece é que você está testando o repositório, o que acredito não ser necessário. Faz-se útil um FakeRepository quando você vai testar um serviço que depende do repositório, usando um fake, você nao precisa se preocupar com setup e teardown do banco.

[Juan Pedro A. Lopes]

Não exatamente, Pedro, pois o banco de dados é o único ponto que não abstraímos. Qualquer API externa é mockada.

E quando a regra de negócio é muito complexa, separamos o máximo do acesso a dados, mas não chegando ao ponto de injetar o mesmo (o que eu também acho horrível). E testamos separadamente.

2010/6/1 higor.cesar <higo...@gmail.com>

[Henry Conceição]

Se eu entendi corretamente, vc faz um unit test para uma implementação
de repositorio que ao inves de acessar o database usa collections para
simular a persistencia e etc? Se sim, isso nao tem valor algum, imho.
Muito pelo contrário, vc esta perdendo um baita tempo criando e
mantendo esse código que nunca é usado pela aplicação.

[higor.cesar]

Exato Henry, penso o mesmo..Parei agora mesmo de fazer isso..rs

[Pedro Reys]

Higor,

Você estava testando o comportamento do repositorio em si, não de algum outro objeto que dependa do repositório, certo?

Nesse caso, também faço dessa maneira. Para testar o repositório em si, uso testes de integração (que acessam a base local de testes). 

Para testar unitariamente objetos que possuam dependencia desse repositorio, ai sim, utilizo stubs que retornam coleção em memória.

- Pedro Reys

2010/6/2 higor.cesar <higo...@gmail.com>

[Phillip Calçado]

Considerando que você faz chamadas à infraestrutura (i.e. banco de
dados, rede, etc.) direto do repositório, mesmo que via NHibernate,
testar este componente unitariamente é mais que inócuo, é perigoso:

http://butunclebob.com/ArticleS.UncleBob.TheDangerOfMockObjects

Você não deveria (na CNTP) criar mocks de objetos que não são seus.

[]s

2010/6/2 higor.cesar <higo...@gmail.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

--
Phillip Calçado
http://fragmental.tw
http://www.fragmental.com.br