openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Olivier,

a few answers:

1) I guess you need to get trained somewhat by C2C to get started. I mean
yes, OERPScenario doc is not a lot currently. But at the same time you can't
expect people to do a lot upfront if Tiny risk to not even consider the
third party work (happened a lot in the past). So once Tiny is committed to
consider it, I guess people can start documenting it better.

2) may be Fabien from Taktik could provide feedback as he told he liked
it...

3) about the allowed! stuff, at some point it's because you tried to pass an
XML/RPC message with nil (equivalent of None) inside which is not allowed by
the spec. Are you sure you sued OOOR 1.2.6 cause we are more defensive now
against that? In any case I suppose I will catch that typical error and
explain better the error. Not too hard.

4) about the speed. Yes, it's not that fast, it's because that's a client
test side. But still, imagine if you used say Selenium it would be much
slower while I think it's decent (I've seen much worst in the real life
testing). So, I think this matches the whole idea of still having almost
unit test along with module to will load quickly while OERPScenrio should
run in the background on a Continuous Integration server after each commit.
Also, please notice that if Tiny were doing a few things Tryton already did,
we could have OOOR like 3 times as fast. Here are the things Tiny can do fro
a fast cross language protocol in general:

- A) add a JSON protocol connector to OpenERP (or YAML which is just a
superset of JSON, as you like). It's a bit the same difference between YAML
and XML: JSON is much more concise, it typically use a tenth of the
bandwidth, has faster parsers/emitters (especially for OOOR where we have
efficient an Java/C backed json parser gem), is human readable. Also it's
more powerful because you can send more in less messages (latency), because
JSON supports sending nested collections (maps and arrays) out of the box
where XML/RPC only allows simple non composite types. At the same time
JSON/YAML is still the anti-soap, it's still as simple as XML/RPC. It could
be used directly by the web-client Javascript framework and skip the dubious
Cherrypy wherever it makes sense and in a nice cross server technology
manner... Tryton uses PySon for their JSON support.

- B) implement things such as search_read methods like in Tryton that can
often skip request and all their associated latency:
https://blueprints.launchpad.net/openobject-server/+spec/search-read-method-such-as-tryton
That would also generally benefit to OpenERP because it would make the
OpenERP GTK client much more usable over the Internet in a Saas prospective.
In the particular case of OOOR, we would continue to totally abstract that
implementation detail in the detail of the find methods, but those would be
twice as fast.

Again, not a top priority compared to 5.2 freeze, but would be great you
consider those options during 2010. We have the same speed limitations
currently when running OOOR inside the Kettle ETL (TerminatOOOR; although
running on JRuby makes OOOR like 3x faster than on CRuby, but latency and
OpenERP slow HTTP layer lag the same way). So for instance we need like 30
minutes to import 3000 oder lines + invoices lines + picking lines +
statements from OScommerce (one month of activity). The real advantage is
that both a trainee or our even customer can understand or alter the Kettle
transfo instead of having to learn OpenERP the hard way but of course, more
speed would be welcome.


NB: a last benefit of OOOR I forgot to mention is also the UML reverse
engineering no other too gives you so far:
http://www.openobject.com/forum/topic14951.html

Hope this helps,

Raphaël Valyi



2010/2/23 Olivier Dony <odo@xxxxxxxxxxx>

> On 23/02/10 12:35, Fabien Pinckaers wrote:
> > Of course we do it. Olivier is testing OERPScenario and will provide a
> > feedback soon.
> >
> > The best way to evaluate is to compare a test case. Let me know if I am
> > wrong, but as far as I understood, if I want to create this test:
> >
> >   - create a partner "Demour SA" with two contacts "Luc" and "Marc"
> >   - check that the credit of the partner==0
> >   - change the name of the partner to "Demour sa"
> >   - test that the new name is "Demour sa"
> >
> > With OEScenario, you have to create these files:
> >   - http://piratepad.net/lPd4U1XdpS
> > (todo by Olivier)
> >
> > With Yaml OpenERP, I create this file in a module:
> >   - http://piratepad.net/mATgKAXiac
>
> As explained, I have made an attempt at writing the above scenario using
> oerpscenario (see http://piratepad.net/lPd4U1XdpS)
>
> Take this as a first try by a java/python dev that must learn some ruby
> on-the-fly to write the scenario. You can certainly provide advice to
> improve the scenario and ruby stuff.
>
> I probably haven't quite understood the philosophy of oerpscenario and
> the way it is supposed to be used, so please correct me if I'm wrong in
> the following early feedback:
>
> 1. It was definitely non-trivial to write the steps definition and get
> the syntax right to make the test work, even with the basic
> documentation provided with ooor and oerpscenario. The barrier is not
> that small for an openobject python developer, I'm afraid.
>
> 2. Debugging errors is a challenge. Even if that's already the case with
> OpenErp, at least I am already familiar with them.
> E.g. here I have no idea why an ActiveResource suddenly calls a random
> "allowed!" method, and how I could solve that.
> (See bottom for some of the errors I encountered)
> It feels a bit sluggish on my machine, but that's probably irrelevant.
>
> 3. I am not sure how this could scale for a large scenario base if we
> have to rely on a small number of oerpscenario developers writing the
> steps definition for everyone else.
> (Compare this with recording the actual scenario in OpenERP directly
> with an improved base_module_record that would output yaml?)
>
> 4. Finally, I really like cucumber's output for the test results.
> Note to team: arrange something similar for regular OpenERP tests!
>
>
> BTW, do any of you know other oerpscenario users/contributors that could
> provide first impression feedback as well?
>
>
>
> -------------------
> For the record and for the oerpscenario experts, here's a shortlist of
> the main errors I encountered. I can write bug reports about these on LP
> if these are actual bugs (you can reply off-list):
>
> - Creating a res.partner.address object using ResPartnerAddress.create()
> or save() does not seem to work, because it calls the strange 'allowed!'
> methods on the res.partner.address object via XMLRPC. I could not find a
> workaround for this.
>
> - Modifying a ResPartner instance and then saving it does not seem to
> work either (see my example on piratepad). This seems to trigger a write
> on all fields of the object, including the relationship fields, which
> does not work (a.o.: passes an array of arrays instead of tuples).
>
>
>
> PS: Raphael, I'm not in the openerp-expert-framework, thanks for adding
> me ;-)
> And while at it, could you include ~openerp in all the expert teams so
> that core team members can directly subscribe to the relevant
> mailing-lists and follow the discussion there? (IIRC I already requested
> this :p)
>
>
> --
> Olivier Dony
>