Testes automatizados

[Fabio Negrini]

Esse link foi postado no twitter, não vi ainda, pois estou só no celular.

http://t.co/1fvkjCot

Enviado do meu HTC

[Renato Lima]

Ola Fábio, na versão 6.1/trunk foi melhorada a plataforma de testes do OpenERP, na branch que eu criei para migração da localização vamos escrever testes nos módulos da localizaçao, eu já até coloque as pastas test nos módulos l10n_br, se vc tiver um tempo hoje queria ver umas coisas com vc

[Fabio Negrini]

Acho que terei sim. Estou em São Paulo hoje e amanhã. Talvez a noite do hotel podemos conversar via voz ao invés de chat.

[Leonardo Santagada]

Eu acho a ferramenta de testes do openerp muito ruim na versão 6.0 Tem
que ver o que eles melhoraram na nova versão mas os defeitos vão
listados aqui:

* Testes não independentes
* Dependencias são implicitas pela ordem de execução
* yaml é uma ferramenta péssima para fazer asserções, a sintaxe é bem
mais pesada do que python
* yaml do jeito que a openerp usou é muito complexo para definir
objetos e a sintaxe não é bem documentada

Os 3 primeiros defeitos foi o que me levou a criar o pytest-oerp, ele
não tem nenhum desses defeitos, e para o quarto problema eu estou
procurando tempo para integrar o lettuce com o pytest e o openerp,
basicamente é portar esse código:
https://github.com/italomaia/flask-lettuce/blob/master/flask_lettuce.py
para o pytest e oerp.

Ah e sobre o uso interno de testes no openerp é muito muito fraco,
alguns modulos só tem testes e eles são muito superficiais, testando
só o muito básico.

[Raphael Valyi]

Ola Leonardo,

eu concordo com o que vc fala. So que tambem eu queria dizer que nao adianta a gente focar em fazer uma localizaçao perfeita se por traz o OpenERP é longe de fazer as coisas perfeitamente. Pois, o nivel de confiabilidade da combinaçao dos trabalhos (localizaçao com OpenERP), sempre vai ser o nivel do pedaço mais fraco, que logo é o proprio OpenERP...

Por isso na Akretion, nao tentamos alcançar a perfeiçao nos padroes Python com a localizaçao. Em vez disso tentamos fazer pelo menos melhor do que a OpenERP SA faz. E em vez de se dedicar a alcançar perfeiçao nalocalizaçao, nos dedicamos recursos para tentar melhorar as coisas do lado do proprio OpenERP. Assim que voce talvez ja viu, nos teremos uns 10 merges nessa 6.1 e varios deles tem como objetivo de melhorar os suporte da localizaçao ou dos nossos modulos de customizaçao.

Por isso isso sugiro que começamos a botar alguns testes com o framework do OpenERP com a localizaçao mesmo assim: se a gente consegue ter uns 60% de coverage com pouco esforço ja seria muito melhor do que o nada que temos hoje. Pelo menos ja seria um start.

Do nosso lado, para testar modulos proprios, costumamos tambem usar o connector OOOR em testes com RSpec ou Cucumber, que nem a CampToCamp faz no OERPScenario. Logo que vc testa do lado cliente, nao tem obrigaçao de fica com a linguagem Python.

Olha eu sou o primeiro para dizer que muitas coisas sao chocantes no codigo do OpenERP. Isso sei desde 2008. Basicamente a turma que começou o codigo do OpenERP é inteligente mas com pouca experiença em programaçao e com Python. Depois de 2009, o outsource na India com a confusao entre "barrato" e "competitivo" nao melhorou muito...

Agora, tambem nao esqueço que ERP's sao quasi sempre uma galeria de horrores, tambem ja gastei alguns meses da minha carreira em tais horrores do lado proprietario, e vai que tinha gente inteligente e bem pago para criar software bem pior... Geralemente no propriprietario, nao é tolerado que a execuçao do trabalho seja tao ruim, mais por outro lado o management corporate acaba com qualquer arquitectura boa como tem em geral no OpenERP. E geralmente o resultado so é bem pior...

Entao, concordo para dizer que o OpenERP é longe se ser perfeito. Para mim o OpenERP so é o melhor dos ERP's livres pelo menos (incluindo a dinamica) e melhor nao quer dizer bom. Na minha opinao, so o Tryton é mais limpo, mas ele ainda esta longe de ter o mesmo alcance nas funcionalidades e no mercado.

Tambem, digo que ha esperança, pois desde 2007, eu vi as coisas sempre melhorar. Claro sempre queriamos que melhora mais rapidamente, mas nao é um projeto pequeno é o modelo open source para a editora nao é tao facil a sustentar. Enfim, no final eu considero que o OpenERP é bom suficente, digamos para um ERP...

-- 

Raphaël Valyi

Founder and consultant

http://twitter.com/rvalyi

+55 21 2516 2954

www.akretion.com

2011/11/16 Leonardo Santagada <sant...@proge.com.br>

[Cristiano Gavião]

Olá pessoal,

na minha humilde opinião, o mais importante, antes de ter testes
automatizados, é ter as histórias (com objetivos claros) e seus
cenários (assim como os dados de exemplo usados) bem descritos, de
forma que o cliente não técnico, possa compreender e confirmar que
aquilo que ele está lendo é o que está comprando e é a garantia que
nós damos do que o sistema deve fazer.

Ferramentas como Jbehave e Cucumber se utilizam desses artefatos de
especificação e ajudam a balisar todo o time técnico envolvido para a
codificação dos testes automatizados e do sistema em si (em artefatos
de programação), além de ajudar na criação do manual de uso.

E foi o que eu achei ruim, na minha curta analise, na ferramenta
utilizada pelo OpenERP:
- dificuldade de contextualizar o teste, pois não há distinção clara,
do que é contexto, do que é evento e do que é ação (como no BDD);
- a obrigação de misturar código com os cenários descritos, tornando
esses artefatos totalmente técnicos.

Olhando por esse angulo, não me importa se o Core OpenERP ou qualquer
uma de suas localizações fora codificado com boas praticas ou não,
desde que cumpra o acordado nas histórias e cenários especificados. :)
Para garantir que o código esteja em padrões de boas práticas, existem
outras ferramentas, pelo menos em java.

abs

Cristiano

> Founder and consultanthttp://twitter.com/rvalyi<http://twitter.com/#!/rvalyi>
> +55 21 2516 2954www.akretion.com
>
> 2011/11/16 Leonardo Santagada <santag...@proge.com.br>

>
>
>
>
>
>
>
> > Eu acho a ferramenta de testes do openerp muito ruim na versão 6.0 Tem
> > que ver o que eles melhoraram na nova versão mas os defeitos vão
> > listados aqui:
>
> > * Testes não independentes
> > * Dependencias são implicitas pela ordem de execução
> > * yaml é uma ferramenta péssima para fazer asserções, a sintaxe é bem
> > mais pesada do que python
> > * yaml do jeito que a openerp usou é muito complexo para definir
> > objetos e a sintaxe não é bem documentada
>
> > Os 3 primeiros defeitos foi o que me levou a criar o pytest-oerp, ele
> > não tem nenhum desses defeitos, e para o quarto problema eu estou
> > procurando tempo para integrar o lettuce com o pytest e o openerp,
> > basicamente é portar esse código:
> >https://github.com/italomaia/flask-lettuce/blob/master/flask_lettuce.py
> > para o pytest e oerp.
>
> > Ah e sobre o uso interno de testes no openerp é muito muito fraco,
> > alguns modulos só tem testes e eles são muito superficiais, testando
> > só o muito básico.
>

> > Em 16 de novembro de 2011 11:07, Fabio Negrini <fnegr...@gmail.com>

> > escreveu:
> > > Acho que terei sim. Estou em São Paulo hoje e amanhã. Talvez a noite do
> > > hotel podemos conversar via voz ao invés de chat.
>

> > > Em 16 de novembro de 2011 11:05, Renato Lima <renatonl...@gmail.com>

> > > escreveu:
>
> > >> Ola Fábio, na versão 6.1/trunk foi melhorada a plataforma de testes do
> > >> OpenERP, na branch que eu criei para migração da localização vamos
> > escrever
> > >> testes nos módulos da localizaçao, eu já até coloque as pastas test nos
> > >> módulos l10n_br, se vc tiver um tempo hoje queria ver umas coisas com vc
>

[Raphael Valyi]

Ola Cristiano,

neste caso, te aconselho de olhar do lado do OERPScenario da CampToCamp (que usa a meu connector OOOR dentro):

http://www.camptocamp.com/fr/blog/2009/10/oerpscenario-the-simple-way-to-write-test-scenario-for-openerp/

Pois ele faz exactamente o que vc quer aqui.

Veja so um resultado:

http://dev.camptocamp.com/files/OERPScenario/result.html

Melhor do que isso fica dificil.

Bom agora, parece que os caras da OpenERP SA sao meio limitado ao Python, entao nao sei se foi por isso o pela vontade de re-inventar a roda que eles fizeram o framework deles, mas enfim, re-inventaram.

Em final de conta, acho que podemos ter alguns testes simples da localizaçao com o framework da OpenERP pois ele nao necessita nehnuma infraestrutura. Como falei, seria um começo e da para testar ja o basico com isso.

Agora, para um projeto de integraçao real, na minha opinao vale a pena investir em coisa que nem a OERPScenario. Ou simplesmente parar apenas no RSpec e nem mexer com Cucumber caso   precisa de agilidade e nao tem ninguem de nao tecnico que ia ler. Ou qualquer outra tecnologia do tipo.

Mas na minha opinao isso ja vai alem do projeto da localizaçao e faz mais parte do jeito que cada um tem de controlar as instalaçoes que ele faz. Pois quando nao se trata do basico, muitas empresas vao ter um jeito bem particular de funcionar. O que vai importar vai ser mais testar que tudo funciona bem de acordo com o funcionamento da empresa e os varios modulos presentes nessa instalaçao X. Entao acho que é um assunto interessante, mas na minha opinao ultrapasse o scope da localizaçao.

Vou pegar um exemplo: quero fazer um teste sophisticado completo: do pedido de venda ate o pagamento: algumas empresas faturam em cima do orçado, outras em cima das expediçoes, outras nem faturam exactamente o que foi orçado (projetos). Uma empresas receber o pagamento antes da nota fiscal, outras depois. Ai, nessas explosao de combinaçoes, voce ja nem consegue fazer um teste que vai ser portavel suficentemente, ele quasi sempre vai ficar quebrado. Por isso na minha opinao isso deve ser feito apenas na hora de testar uma implementaçao X, provavelmente re-aproveitando pedaços de outros testes.

Atts.

-- 

Raphaël Valyi

Founder and consultant

http://twitter.com/rvalyi

+55 21 2516 2954

www.akretion.com

2011/11/17 Cristiano Gavião <cvga...@gmail.com>

[Leonardo Santagada]

Em 17 de novembro de 2011 15:44, Cristiano Gavião <cvga...@gmail.com> escreveu:
> Ferramentas como Jbehave e Cucumber se utilizam desses artefatos de
> especificação e ajudam a balisar todo o time técnico envolvido para a
> codificação dos testes automatizados e do sistema em si (em artefatos
> de programação), além de ajudar na criação do manual de uso.

O lettuce é um port do cucumber e é exatamente por isso que estou
querendo portar ele para rodar dentro do pytest, assim dá para rodar
os testes de aceitação/bdd junto com os outros testes e com suporte a
independencia e transações. :)

[Leonardo Santagada]

Em 17 de novembro de 2011 16:08, Raphael Valyi <rva...@gmail.com> escreveu:

neste caso, te aconselho de olhar do lado do OERPScenario da CampToCamp (que usa a meu connector OOOR dentro):

http://www.camptocamp.com/fr/blog/2009/10/oerpscenario-the-simple-way-to-write-test-scenario-for-openerp/

Pois ele faz exactamente o que vc quer aqui.

Veja so um resultado:

http://dev.camptocamp.com/files/OERPScenario/result.html

Melhor do que isso fica dificil.

Bom agora, parece que os caras da OpenERP SA sao meio limitado ao Python, entao nao sei se foi por isso o pela vontade de re-inventar a roda que eles fizeram o framework deles, mas enfim, re-inventaram.

O framework do openerp não parece com o cucumber, é na verdade muito pior. O importante de usar só uma linguagem num sistema como o openerp é justamente tu não ter que ser bom em duas linguagens ao mesmo tempo, principalmente no aso de ruby e python que tem o mesmo poder de abstração usar ambas faz muito pouco sentido.

O problema que eu vejo do openerpscenario é o não controle das transações porque ele usa a api de rpc do open que não tem suporte a transações o que limita muito em como separar um teste do outro.

A lettuce é um port do cucumber para python e funciona muito bem, e além de tudo é feita por brasileiros então o suporte a testes em português é bem bom.

[Raphael Valyi]

2011/11/17 Leonardo Santagada <sant...@proge.com.br>

Em 17 de novembro de 2011 16:08, Raphael Valyi <rva...@gmail.com> escreveu:

neste caso, te aconselho de olhar do lado do OERPScenario da CampToCamp (que usa a meu connector OOOR dentro):

http://www.camptocamp.com/fr/blog/2009/10/oerpscenario-the-simple-way-to-write-test-scenario-for-openerp/

Pois ele faz exactamente o que vc quer aqui.

Veja so um resultado:

http://dev.camptocamp.com/files/OERPScenario/result.html

Melhor do que isso fica dificil.

Bom agora, parece que os caras da OpenERP SA sao meio limitado ao Python, entao nao sei se foi por isso o pela vontade de re-inventar a roda que eles fizeram o framework deles, mas enfim, re-inventaram.

O framework do openerp não parece com o cucumber, é na verdade muito pior. O importante de usar só uma linguagem num sistema como o openerp é justamente tu não ter que ser bom em duas linguagens ao mesmo tempo, principalmente no aso de ruby e python que tem o mesmo poder de abstração usar ambas faz muito pouco sentido.

O problema que eu vejo do openerpscenario é o não controle das transações porque ele usa a api de rpc do open que não tem suporte a transações o que limita muito em como separar um teste do outro.

O problema é que o framework vai te fazer varios commits em muitos lugares (so procurar cr.commit() nos addons, nao falta). Por isso, de qualquer forma acho que é melhor usar os "savepoints" do Postgres caso quiser tentar re-approveitar os testes melhor. Caso quiser usar savepoints, nao faz diferençà se vc esta do lado client que nem no OERPScenario.

A minha opinao sobre os linguagens nao é a mesma: considero que nessa altura aprender varias linguagens abre os horizontes e deixa o programador melhor. Pois ja estamos falando de um certo nivel para mexer com um ERP, mas enfim, cada um tem a sua opinao.

De qualquer forma, acho que qualquer iniciativa a respeito de testar mais e boa, embora o framework de test. Depois sempre tera um jeito de integrar os testes que um ou outro faz. Por examplo, mesmo que ainda nao integrados, varias regressoes ja foram detectadas pela CampToCamp com o OERPScenario deles.

 

A lettuce é um port do cucumber para python e funciona muito bem, e além de tudo é feita por brasileiros então o suporte a testes em português é bem bom.

Em geral e boto mais confiança (e procurar entender as escolhas delas) nas pessoas capaz de fazer o original do que apenas produzir uma copia, mas esse Lettuce e provavelmente bem valido tambem. 

[Cristiano Gavião]

Oi Raphael,

Respostas inline abaixo....

abs

On 17/11/11 15:08, Raphael Valyi wrote:

Ola Cristiano,

neste caso, te aconselho de olhar do lado do OERPScenario da CampToCamp (que usa a meu connector OOOR dentro):

http://www.camptocamp.com/fr/blog/2009/10/oerpscenario-the-simple-way-to-write-test-scenario-for-openerp/

Pois ele faz exactamente o que vc quer aqui.

Veja so um resultado:

http://dev.camptocamp.com/files/OERPScenario/result.html

Melhor do que isso fica dificil.

Exatamente algo assim é que estou me referindo... bem bacana... 

Eu uso o jbehave de maneira bem semelhante.

Acredito que a ferramenta criada por vc seja a responsável por fazer a ponte entre o cucumber/ruby e o ambiente python, estou correto ? por acaso com ela vc consegue controlar o inicio do servidor, a carga de dados e pré-instalação e configuração de módulos para o teste também, ou é necessário fazer isso manualmente ?

Bom agora, parece que os caras da OpenERP SA sao meio limitado ao Python, entao nao sei se foi por isso o pela vontade de re-inventar a roda que eles fizeram o framework deles, mas enfim, re-inventaram.

Não sei se seria o python o culpado disso, coitado :)  afinal pude verificar que existem várias ferramentas nativas a ele como:  lettuce, Pyramid e Fresh, que seguem a mesma linha do cucumber/ruby...

Talvez tenha sido uma mistura de pensamento time-box (temos que ter algo funcionando em 20 dias, depois vemos como vamos melhorar), com outras prioridades depois da versao 0.1 lançada e somados a uma falta de visão mais ampla do potencial... :D

Imagina só se eles utilizassem uma ferramenta on-line para que as pessoas pudessem contribuir e manter os cenários de testes (podendo até mesmo ser localizados), como é feito hoje para manter traduções com o Rosetta...

Em final de conta, acho que podemos ter alguns testes simples da localizaçao com o framework da OpenERP pois ele nao necessita nehnuma infraestrutura. Como falei, seria um começo e da para testar ja o basico com isso.

Concordo, já que é a maneira mais fácil e rápida de ter algo funcionando... 

Agora, para um projeto de integraçao real, na minha opinao vale a pena investir em coisa que nem a OERPScenario. Ou simplesmente parar apenas no RSpec e nem mexer com Cucumber caso   precisa de agilidade e nao tem ninguem de nao tecnico que ia ler. Ou qualquer outra tecnologia do tipo.

Sem dúvida, e acabei de fazer um mini-teste aqui com o módulo web. Como é web e roda em browser, daria para usar também o jbehave-web (http://jbehave.org/reference/web/stable/page-objects.html), que usa o selenium para interagir com o browser.... mas como é java, eu teria que criar um módulo para poder interagir com o servidor no command-prompt para de alguma forma poder fazer a contextualização de cada teste...

Mas na minha opinao isso ja vai alem do projeto da localizaçao e faz mais parte do jeito que cada um tem de controlar as instalaçoes que ele faz. Pois quando nao se trata do basico, muitas empresas vao ter um jeito bem particular de funcionar. O que vai importar vai ser mais testar que tudo funciona bem de acordo com o funcionamento da empresa e os varios modulos presentes nessa instalaçao X. Entao acho que é um assunto interessante, mas na minha opinao ultrapasse o scope da localizaçao.

Bom, com relação ao escopo da localização, eu acredito que devam conter os testes de histórias que estão sendo atendidos por ela, por exemplo: A criação do plano de contas tupiniquim, a configuração e emissão de NFe, etc.

Vou pegar um exemplo: quero fazer um teste sophisticado completo: do pedido de venda ate o pagamento: algumas empresas faturam em cima do orçado, outras em cima das expediçoes, outras nem faturam exactamente o que foi orçado (projetos). Uma empresas receber o pagamento antes da nota fiscal, outras depois. Ai, nessas explosao de combinaçoes, voce ja nem consegue fazer um teste que vai ser portavel suficentemente, ele quasi sempre vai ficar quebrado. Por isso na minha opinao isso deve ser feito apenas na hora de testar uma implementaçao X, provavelmente re-aproveitando pedaços de outros testes.

Humm, nesse ponto eu concordo e discordo.  Sempre que vamos implementar histórias, como por exemplo: Lançamento de Pedidos de Venda, Faturamento de Pedidos, Recebimento de Pagamento de Pedidos, etc, existe uma chance enorme de estas histórias se desdobrarem em diversos cenários diferentes. E cada um deles pode ter necessidades de contextualização diferentes (um ou outro de módulo pré-instalados, registros pré-carregados na base de dados, usuários com permissões especiais já logado, serviços externos levantados, equipamentos operacionais, etc), com ações de usuário diferentes, e no final, ter respostas do sistema também diferentes. Isso faz parte do jogo, mas desde que os contextos estejam atendidos, não é pra quebrar...  mas claro, uma empresa poderia que ter os cenários que utilizam modificados para atender as suas realidades...

E especificamente nesse caso é aonde as ferramentas BDD (como cucumber, jbehave, o seu OERPScenario, etc) são bacanas e altamente produtivas. Isso é verdade pois sempre podemos reusar códigos de testes já criados, e em alguns casos até mesmo cenários já descritos (já que o código do teste é escrito em artefato diferente da cenário). e isso é ainda mais perceptível quando estamos criando o sistema do zero.

Oque eu não posso fazer (dentro do meu processo, claro) é ter uma funcionalidade liberada para o usuário, sem os devidos cenários descritos. Mas como disse, isso é mais fácil qd o sistema já nasce com esse conceito em mente.. :)

abs

[Cristiano Gavião]

Oi Leonardo,

Vc poderia me mandar um exemplo de como vc se utiliza de transações em BDD ?

Como eu só faço testes "caixa preta" e normalmente a partir da interface
de usuário, eu nunca precisei trabalhar diretamente com isso, no máximo
eu executo (e as vezes reuso) um ou outro cenário para poder Definir um
Contexto para o teste (por exemplo, adicionar um registro no banco)

Veja um pedaço de um cenário em um sistema que fiz (tá cortado):

História: Lançamento de Nota Fiscal

Cenário: Auxiliar Administrativo deve poder lançar nota de serviço com
mão de obra, de fornecedor não optante do simples, para dois centros de
custo e
pagamento em 3 vezes.
// Serviços com mão de obra exigem que se selecione uma categoria que
tenha o imposto INSS associado, como Segurança.

Dado que exista os seguintes dados na tabela "Categorias":
|codigo|Descrição|
|1|Serviço de Vigilância|
E que o usuário 0001 esteja devidamente autenticado com Auxiliar de
Administrativo
E a página corrente seja "Lançamento de Contas a Pagar"
Quando o usuário preenche o formulário "Conta a Pagar" com os seguintes
dados:
|usuario|fornecedor|optanteSimples|dataReferencia|tipoDocumento|dataEmissao|...

|0001|1|não|19/09/2009|NFS-A|15/09/2009|....
E preenche o formulário "Lançamentos" com os seguintes dados:
|centroCusto|valor|categoriaLancamento|
|1|5000,00|Serviço de Vigilância|
|2|5000,00|Serviço de Vigilância|
Então o sistema apresenta o formulário "Impostos" preenchido com os
seguintes valores calculados:
....

abs

Cristiano

[Leonardo Santagada]

Em 17 de novembro de 2011 18:24, Raphael Valyi <rva...@gmail.com> escreveu:

2011/11/17 Leonardo Santagada <sant...@proge.com.br>

Em 17 de novembro de 2011 16:08, Raphael Valyi <rva...@gmail.com> escreveu:

neste caso, te aconselho de olhar do lado do OERPScenario da CampToCamp (que usa a meu connector OOOR dentro):

http://www.camptocamp.com/fr/blog/2009/10/oerpscenario-the-simple-way-to-write-test-scenario-for-openerp/

Pois ele faz exactamente o que vc quer aqui.

Veja so um resultado:

http://dev.camptocamp.com/files/OERPScenario/result.html

Melhor do que isso fica dificil.

Bom agora, parece que os caras da OpenERP SA sao meio limitado ao Python, entao nao sei se foi por isso o pela vontade de re-inventar a roda que eles fizeram o framework deles, mas enfim, re-inventaram.

O framework do openerp não parece com o cucumber, é na verdade muito pior. O importante de usar só uma linguagem num sistema como o openerp é justamente tu não ter que ser bom em duas linguagens ao mesmo tempo, principalmente no aso de ruby e python que tem o mesmo poder de abstração usar ambas faz muito pouco sentido.

O problema que eu vejo do openerpscenario é o não controle das transações porque ele usa a api de rpc do open que não tem suporte a transações o que limita muito em como separar um teste do outro.

O problema é que o framework vai te fazer varios commits em muitos lugares (so procurar cr.commit() nos addons, nao falta). Por isso, de qualquer forma acho que é melhor usar os "savepoints" do Postgres caso quiser tentar re-approveitar os testes melhor. Caso quiser usar savepoints, nao faz diferençà se vc esta do lado client que nem no OERPScenario.

Que eu saiba um savepoint é algo parecido com uma subtransação, tu não pode fazer rollback para um savepoint antes do começo da transação então não é util para voltar várias transações. Nesse caso com o postgresql a unica forma seria usando PITR, que é meio trabalhoso.

não tem tantos modulos que fazem commit
(nos addons-extra tem mais, mas lá é uma bagunça):

addons $ ack -l "\.commit\(\)" | cut -d "/" -f 1| uniq
base_crypt
audittrail
document_ftp
document
procurement
users_ldap
document_webdav
base_report_designer
base_action_rule

Então eu não vejo problema em realmente usar as transações... fora que é bem fácil fazer uma subclasse que não faça commit das transações.

A minha opinao sobre os linguagens nao é a mesma: considero que nessa altura aprender varias linguagens abre os horizontes e deixa o programador melhor. Pois ja estamos falando de um certo nivel para mexer com um ERP, mas enfim, cada um tem a sua opinao.

Claro mas linguagens diferentes. Python e Ruby são tão parecidas que nem tem graça aprender ambas. O principal é que forçar os usuários a realmente saber bem ambas e conseguir manejar as diferenças semanticas entre ambas para testes/desenvolvimento não faz muito sentido

 

De qualquer forma, acho que qualquer iniciativa a respeito de testar mais e boa, embora o framework de test. Depois sempre tera um jeito de integrar os testes que um ou outro faz. Por examplo, mesmo que ainda nao integrados, varias regressoes ja foram detectadas pela CampToCamp com o OERPScenario deles.

 

A lettuce é um port do cucumber para python e funciona muito bem, e além de tudo é feita por brasileiros então o suporte a testes em português é bem bom.

Em geral e boto mais confiança (e procurar entender as escolhas delas) nas pessoas capaz de fazer o original do que apenas produzir uma copia, mas esse Lettuce e provavelmente bem valido tambem.

Isso não faz nenhum sentido, tu precisa de uma ferramenta de testes tipo cucumber no python o unico jeito de ter isso é fazer uma cópia. Falando nisso o OpenERP não é o primeiro ERP e é só uma cópia de vários outros.

[Leonardo Santagada]

Em 17 de novembro de 2011 20:13, Cristiano Gavião <cvga...@gmail.com> escreveu:
> Vc poderia me mandar um exemplo de como vc se utiliza de transações em BDD ?
>
> Como eu só faço testes "caixa preta" e normalmente a partir da interface de
> usuário, eu nunca precisei trabalhar diretamente com isso, no máximo eu
> executo (e as vezes reuso) um ou outro cenário para poder Definir um
> Contexto para o teste (por exemplo, adicionar um registro no banco)

Por exemplo, tu num teste pode configurar o OpenERP para por default
fazer uma operação, no fim do teste tu não precisa limpar as
preferencias de volta porque a transação criada durante o teste vai
receber um rollback. Outro exemplo é se tu cria um objeto em
especifico e modifica ele e testa, quando for rodar o teste de novo
poderia acontecer um erro porque o objeto já existe (por exemplo se
ele tem campos que não permitem duplicados no postgresql). Outro
exemplo é a independencia dos testes, um teste pode falhar ou passar
porque outro rodou antes, e ai quando for rodar apenas um teste ele
falha, ou o pior, em produção a feature não funciona.

Isso tu usa na parte de implementação do BDD, no arquivo do
lettuce/cocumber teoricamente tu não ve diferença nenhuma, só na parte
em python que implementa o teste e no aumento consideravel de robustes
e utilidade do teste.

[Cristiano Gavião]

Olá,

Agora entendi o seu ponto... :)

Sem dúvida essa independência é mesmo necessária...
No meu caso, para isso, eu me utilizo de um módulo que criei em cima do
jbehave que usa o JPA.
A cada teste, eu faço uma "limpeza da base de dados" (faço um drop) e
configuro um novo contexto (faço uma carga de dados) para o próximo
teste ... QQ dia desse vou tentar com rollback para ver se dá diferença
na performance..

valeu

abs

[Leonardo Santagada]

Em 19 de novembro de 2011 12:56, Cristiano Gavião <cvga...@gmail.com> escreveu:
>
> Sem dúvida essa independência é mesmo necessária...
> No meu caso, para isso, eu me utilizo de um módulo que criei em cima do
> jbehave que usa o JPA.
> A cada teste, eu faço uma "limpeza da base de dados" (faço um drop) e
> configuro um novo contexto (faço uma carga de dados) para o próximo teste
> ... QQ dia desse vou tentar com rollback para ver se dá diferença na
> performance..
>

Olha depende da tua base, mas é pra ser de 10x a milhões de vezes mais
rápido (no caso do openerp). A base com os modulos da localização e
tudo mais leva uns bons 20 segundos para ser carregado, enquanto um
rollback de transação (numa maquina com pg configurado para
desenvolvimento) leva alguns milisegundos.