openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Hello guys,

OOOR-1.2.7 has been released, see changes/roadmap here:
http://www.openobject.com/forum/post51702.html
sudo gem update ooor
to upgrade.

At the same time, we took care of Oliver's remarks about type! or allowed!
methods being mysteriously fired to OpenERP (as consequences of earlier
errors) and we now catch them defensively earlier to make error more
obvious.
We also took care of Joêl need for better exception handling, sorry it was
not good enough before, now you can finally catch any OpenERP Runtime error
in OERPScenario if you like.
We fixed a few more corner cases issues and introduced native support for
ir_model_data ids as explained in the forum which will help for testing I
guess (we actually were needing that a lot for Kettle and Rails scripts).

Olivier,
one important thing that would help you get your feet on the ground with
OERPScenario is to enable the logs (in lib/ERPConnector.rb ) at info level
so you see all RPC request just like in the OpenERP GTK client. Joêl I think
you should better make this more obvious in the doc or config.
It's also much easier to experiment with your test in an irb console
following OOOR API http://github.com/rvalyi/ooor (anything missing here?)
and putting them in Cucumber only once you have a good prototype/are used to
it. By default OOOR is in verbose logging mode.
And again, if our goal was just to compete with plain YAML terseness we
would just write the tests using OOOR only (and we would be as terse yet
more powerful) but as we said, the whole idea behind Cucumber is different
and is really to allow non tech folks to participate and be able to
understand what is actually tested/missing. Now I believe nothing would get
you started better than spending a half hour on Skype with C2C...

Hope you enjoy it


Raphaël Valyi
http://www.akretion.com


2010/2/23 Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>

> Hi Fabien Lyoire,
>
>
> I agree with everything you said !
>
> Thanks for your input and ... lets write tests ;) !
>
> Regards,
>
> Joël
>
>
> Le 23 févr. 2010 à 18:47, Fabien Lydoire a écrit :
>
> Hi everyone,
>
> I'm "Fabien from Taktik" :)
>
> First of all, I'd like to say I was neither a python nor a ruby developer.
> It's been 2 years I've been working on OpenERP.
> We've been integrating OpenERP for a client that wanted to use it widely,
> and we found (a lot of) bugs here and there.
> There are also some performances issues happening on a "real life" database
> (my client encoded everything from 1/1/2009).
>
> I think the situation with dynamic languages is that the code must be
> widely tested.
> This is obviously not the case for OpenERP
> An ERP is very complicated, and there could be many combinations with
> modules installed/not installed.
> I was more than happy when I discovered OpenERP Scenario even if at first I
> was not very happy with the idea of learning another language (ruby).
>
> But there are just a few instructions/syntax to learn : if you are a
> developer, you can manage this in a few hours.
> The output of OpenERPScenario is really great : this is something you can
> attach to a delivery report for your client (although the pdf output could
> be nicer).
> The text part can/should be written by non developer smart enough to write
> the same sentences (so that you can catch them).
>
> The error messages are as bad as the OpenERP ones (bool object is
> unscriptable).
> I prefer getting an error message in my scenario rather than my customer
> gets it once he clicks a button.
>
> The whole point is to be able to test from the client side (since this is
> what's gonna be used) the OpenERP server behavior.
>
> OpenERP Scenario can be useful :
> - to check is there are bugs in the server,
> - to check if data are consistent,
> - to check with the business expert if the module is correct,
> - to present a report ensuring that a set of functionality works.
>
> Right now, in the current state of internal server tests and OpenERP
> scenarios, NO ONE can ensure that OpenERP works when installed.
>
> Certified modules have still huge bugs, and sometimes are wrong about the
> business they should be a model of.
>
> We ALL know that OpenERP need a test suite.
> The test suite will be a HUGE work, I think hundreds of tests are needed to
> ensure OpenERP works as expected/advertised.
>
> I understand the need for buzz/fancy new stuff to show OpenERP is moving
> on, and to get fund raising, and to have something new to show on commercial
> events.
> Therefore the resources allocated for testing are reduced.
>
> Nevertheless, you can not sell an ERP without checks.
> These checks are absolutely needed.
> OpenERP has been developed without extensive test through the years.
> It's time to get a professional product, not something you cross your
> fingers to make it work.
>
> Resources being limited, I think we should focus on a single test suite,
> and Tiny sprl has been unable/unwilling to make a decent test suite.
>
> That's why my choice is for now OpenERP Scenario.
> Join us, let's write those hundreds of tests, and let's get a
> better/professional product !
>
>
> To answer the former mails, I think:
> - that any developer can manage writing a few lines of ruby,
> - that having test from outside the server is a good thing : self-diagnosis
> are good but not enough,
> - that staying in the python world is a lack of opening,
> - that OpenERP should use extensively other projects that could suit its
> needs, even if it's not python, instead of re-inventing the wheel,
> - that no-one but integrators will write tests (regardless of the
> technology used),
> - that tests should be written with the help of business people. OpenERP
> has been developed by computer science guys, not business guys : I've shown
> account reports to accountants and according to them, they were all craps
> (when we were able to get it, see performances tests on the real life
> database). The test is not only a computer test, it must also test the
> business...
>
> Finally, if it were my product, I would do a "functionality freeze", write
> a ton of tests, and deliver a debugged app.
>
> Regards,
>
> Le 23 févr. 2010 à 17:57, Raphaël Valyi a écrit :
>
> 2) may be Fabien from Taktik could provide feedback as he told he liked
> it...
>
>
> _______________
> *Fabien Lydoire*
> Software Engineer
> Email : fl@xxxxxxxxx
> GSM : +32 497 411 182
> _______________
> *TAKTIK SA*
> Grote Baan 225
> 1620 Drogenbos
> Tel : +32 2 333.58.40
> Fax : +32 2 648.16.53
> http://www.taktik.be
>
>
>
> <logo-taktik.gif>
>
>
>
> --
>
>
> *Joël Grand-Guillaume** *
> *Division Manager*
> *Business Solutions*
> *
> *
> *Camptocamp SA*
> PSE A, CH-1015 Lausanne
>
>  www.camptocamp.com
>
>
> Phone: +41 21 619 10 28
> Office: +41 21 619 10 10
> Fax: +41 21 619 10 00
> Email: joel.grandguillaume@xxxxxxxxxxxxxx
> http://www.camptocamp.com/fr/business-solutions/formations
>
>