openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Hello guys,

Fabien, we are very happy with the fact OpenERP now consider OERPScenario
and BDD!
At the same time I apologize because that was still OOOR-1.2.6 on Gemcutter,
I had to repush it, now it's really 1.2.7.
sudo gem install ooor
to upgrade.

Still, Fabien, you see, I think I'm as obstinate as you, so even if we now
clearly agree upon the philosophical differences between embedded tests and
external client-side full blown functional tests, I still make 2 points on
details about your last statements:

1) when you say you can call Python from YAML:
yes you could but:
  - what you get is OpenERP API with awkward
self.pool.get('product.product').write(cr, uid, {taxes_id: [6,0, [1,2]]})
instead of OOOR product.taxes_id = [1,2] ... Don't get me wrong, I like the
batch oriented API, I think it's perfect for server side coding, but I don't
think that's user friendly nor it makes a lot of sense in a client consumer
prospective (I even think the batch API is totally abused in the on_change
methods that are never batch oriented in reality).
  - OOOR reproduce the client state, when you click on an on_change or
wizard button, the current object will hold the changes. By using raw Python
you would need to deal with those values that manually with no clean
consumer oriented abstraction.


2) when you say you could record tests with the test recorder and skip tech
guys  -> excuse me but as Joêl said, LOL and re LOL
All right, I would rather translate this to: people could then record tests
(and this is very good don't get me wrong)
BUT, at the end of the day, developers will again need to clean it manually,
just like for OERPScenario.

Why?
Simple:
- base_module_record do not properly deal with dependencies: it does not
know which object field is brought by which module so it just save all
fields so if you try to use the test with some missing module it doesn't
work (so as long as you try complex scenario with lot's of modules just to
ensure compat is preserved it will then depend on all those modules unless
manually cleaned up).
- it will require work for you to formalize expectations in something like
module_recorder, and I'm 100% it won't be fined grained enough to be 100%
automatic
- you have no save point management and again, would be nothing easy to make
tools for that (I work with Jython based test recording tools like QFTestJui
and they spend a lot of man months per year to achieve that tooling and at
the end of the story it's less powerful than Cucumber...)

This reminds me when you developed the module_recorder and view "designer"
(and we are yet to see that Dia stuff...). Those are certainly great helps
for the noobs and great slideware to sale OpenERP (I'm serious, they are
great for that and we appreciate it and your investors certainly like it
too). Now, you know perfectly that nearly 2 years later, no integrator nor
Tiny (hey would any thing base_module_creator would take the initiative to
call an XML id panding_invoice? nope that was the signature of Tiny ;-) use
those tools to build the core modules because they only work at 80% (ugly
output code, heisenbugs, API limitations), so luckily it's still done
manually and it's better this way until the tooling can get VERY mature.

So, we really like the increased ability to record tests using the module
recorder. It's just that I don't think it's fair when you say hey
OERPScenario require tech guys, we don't require them.
We aren't trying to raise funds anymore, we can now afford to be fair again
;-) only real features will make real sustainable money from now on...

Tooling is great, but because it actually takes a lot of resource to build
mature tooling, it's very important to first make sure low level
code abstractions are efficient (declarative at least and usable directly by
power users). That's the whole difference between say .Net/Flash/JavaFX and
things more hardcore like Rails/OpenERP and we see which paradigm is
winning. The "clickers" are loosing terrain because their code generation
had no long term value/quality and because it costs a lot to maintain the
illusion of automation. Tooling should always come second. Now, again YAML
is 100% what should be done so it's very welcome.
BTW, if you or your devs had "wasted" time with say Ruby/Rails, you would
have thought about YAML much earlier (I see that new Python web frameworks
are trying to copy HAML/SASS too) and would have a better readability of the
existing codebase, so just one argument against the looking elsewhere is a
waste of time..

Again those are minor remarks, we are very happy by the new stance regarding
tests.
Let me know if anybody has trouble with OOOR. At the same time you can count
on us to test what makes sense with YAML demo data/basic expectations. We
even reuse those in OERPScenario so we need them at 200%.

Now, I'm even more excited if OpenERP sa (cool down I'll stop calling you
Tiny) does what had tells here http://openerp.com/forum/topic15358.html
search_read (and JSon would just be killer too).

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


2010/2/24 Fabien Pinckaers <fp@xxxxxxxxxxx>

> Hello,
>
> I think it's important to note that OERPScenario and Yaml allows to do
> exactly the same things:
>
> * both allows to call Python code. In yaml, you can do something like:
>  !python
>    self.search(cr, uid, ...)
>    ...
> * both allows to reuse preceeding tests. In OERPScenario you define
> reuseable regex, in YAML you define anchor and aliases.
>
> * both allows to write tests in two steps:
>  1. a functional describe the test
>  2. a developper code/implement the test
> -> in yaml it's in one file, in OERPScenario it's in two files, linked
> by regexes.
>
> Here are the real difference:
>
> 1. OERPScenario is more based on code, whereas yaml is more based on
>   data
> 2. As YAML is purely data, tests can be generated by the module
>   recorder, in OERPScenario every test requires development (usualy
>   quite simple, 2 lines of code) -> so no need to ask a developer
>   to implement at all.
> 3. OERPScenario has a very clean and beautiful output, YAML has a text
>   output, but not beautiful at all
> 4. OERPScenario is more complex to learn than YAML, which is just
>   another way of encoding current .XML files of OpenERP
> 5. YAML is a uniq system for (demo) data and tests
>
> > Non-devs people will NEVER EVER be able to write tests case in a
> > technical way ! this is why someone smart invent the Gherkin syntax...
> > With this, business people only care on the Scenario, tech people
> > about coding it...
>
> Yes, you can. Selenium does it.
>
> We can also do it through the module recorder in OpenERP. Quite easy:
> click on start recording, do all your operations, click on stop
> recording and it gives you the yaml file. So, you don't need the tech
> people to develop it.
>
> With YAML, you can also do the same than in OERPScenario:
>
> 1. A non-dev write the tests case:
>
> -
>  Given I have created a partner named "Demour SA" with the following
> addresses:
>           | Luc  |
>           | Marc |
> -
>    Then I expect the partner credit to be 0
> -
>    And when I change the partner name to "Demour sa"
> -
>    Then I expect the partner name to be "Demour sa"
>
> 2. The technical implements each test between each lines to finally get
> this: http://piratepad.net/mATgKAXiac
>
>
>
> I think we can speak hours to argue on both solutions. Both are good and
> both have disadvantages and advantages. Here is my conclusions for our
> company:
>
> * We promote both
> * In v5.0, OERPScenario is the only solution
> * In future versions and trunk, YAML only will be used by our developers
>  for demo data and tests
>
> I suppose C2C and Rvalyi will use OERPScenario for v5 and trunk and
> that's good. -> We will may be find twice as more bugs.
>
>
>
>
>
> Both solutions may answer different needs:
> 1. As the editor, we have to take the easiest solution and fastest
>   solution to develop tests, integrated in OpenERP
> 2. As an implementer, you probably need a clean output for your tests so
>   that you can show them to your customers.
>
>
> One thing is sure, let's stop this small fighting "You must use this,
> not this one" or "This one is better". Let's just start promoting both.
>
> Let's start another debate :)
>  - do we also have to use selenium to test the client interface ?
>
> thanks,
>
>
> --
> Fabien Pinckaers
> CEO Tiny - OpenERP Editor
> Chaussée de Namur 40
> B-1367 Grand-Rosière
> Belgium
> Phone: +32.81.81.37.00
> Fax: +32.81.73.35.01
> Web: http://openerp.com
>
> Great Achievements Start With Tiny Investments
>  -- Marty, 2005
>