openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Hello Colves,

I strongly agree with your call for refactoring test. Still within the
refactoring their is a whole class of actions that are safe. It's about
identifying them, planning them and doing them. For instance, something that
is safe and easy to test manually is method extraction, that's almost a
button click in an IDE and would save use from large methods that are then
copied pasted all over the place rather than overridden. The main one I've
spotted over my integrator life:
https://blueprints.launchpad.net/openobject-addons/+spec/code-refactor-for-better-extensibility

As for functional testing, OERPScenario is ready and great. Selenium would
IMHO be very counter productive because the HTML layout would easily change
when you install modules / refactor the HTML and all tests would breaks, not
too say it would be slow and require an X Window, possibly disabling a
developer PC. OERPScenario already tests on the the client side but at the
message level, not the View level. Then I think Tiny can unit test
separately that clients to produce the expected results provided some
messages entries, rather than paying the burden to pay that view layer for
all the functional testing. I had a very bad experience in a GDS company
with functional testing at the view level: testing costs raised out of
control, people quit because it was too boring... We need to stick to a
smart way...

IMHO, 5.2 will not show yet any benefit of testing (except may be the
OERPScenario suite by CampToCamp) because it's too close now, so only the
safe/manually tested refactoring would enter. However, they would still save
us days of debugging if we do them rather than delay them again forever.
Now, my view is that during the 5.2 a test suite can still be built and
since 50% of the bugs can be fixed without breaking the API, then that bug
fix can come during the 5.2 life.

Now, my concern is rather Tiny to anticipate the main API changes to be made
for the other bugfix to concentrate it for 5.2 rather than having to do it
silently during 5.2 as it were done during 5.0 or either dooming OpenERP not
to receive that bugfix during the whole 5.2 lifespan while yet an other set
of modules will be made upon that brittle basis with future bugs etc..

In any case, YAML is a great news. I do not consider it a priority because
it will not show results for the 5.2 freeze yet (even if a better test
framework exists, new tests won't be there yet), so I consider the API
change/safe required refactoring more important for that deadline. Now I
hope 5.4/6 would finally benefit from a test culture yes, possibly leading
to a wider market thanks to lower integration costs.

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


2010/2/19 Cloves Almeida <cjalmeida@xxxxxxxxx>

> Hi Raphael,
>
> IMO, functional tests are top priority. OpenERP is big, complex,
> decentralized and is starting to age. Unlike Tryton, the somewhat large
> install base makes regressions a very costly issue. Couple that with being
> written in a dynamic language and every single change could introduce large
> unexpected errors. In IT, "Enterprise" means "no surprises".
>
> Some old modules like "account" need refactoring badly, but without tests,
> those are shots in the dark. Tiny doesn't even have to write the tests, but
> just establish the standards. Be it OERPSenario, or Selenium or whatever,
> Tiny should pick one and coordinate the effort.
>
> If I could propose something, the 5.2 feature freeze should last until a
> 5.4 release 3-to-6 months from now which would focus only on tests and
> refactorings. After that initial sprint, I'm confident the developers will
> absorb the "test culture".
>
> Raphaël Valyi escreveu:
>
>> Hello Cloves,
>>
>> not analysed that your proposal yet, but I let you know (they told us at
>> the IRC community meeting) that Tiny has finally understood the benefit of
>> loading data with YAML, and idea both of us have been actively defending.
>> They are interested in making it possible in 5.2 (I still insist that there
>> are more urgent refactoring to be done first rather than let module build on
>> sand). Their primary interest is to make it less cumbersome to write
>> ~unit/~functional tests embedded with modules (evolving their current test
>> framework). IMHO this is very welcome but wouldn't question OERPSenario
>> which is the only tool able to test complex cross modules features in a
>> business readable way (Cucumber based). Still, aside from their pseudo unit
>> test, it would be very welcome to be able to use YAML to load data/do the
>> ERP customization instead of the XML unreadable bloat, at least those coming
>> months were the RAD tools are not yet usable for serious integrator usage,
>> past the slideware. If you have resources, you can try to team with Xavier
>> Morel or Julien Thewys from Tiny/OpenERP which seems tracking that feature.
>>
>> Happy to see YAML and tests gaining mindshare at Tiny.Will analyse that
>> new proposal later hopefully, thank you for contributing.
>>
>> Raphaël Valyi
>> http://www.akretion.com
>>
>>
>> On Wed, Feb 17, 2010 at 7:47 PM, Cloves Almeida <cjalmeida@xxxxxxxxx<mailto:
>> cjalmeida@xxxxxxxxx>> wrote:
>>
>>    About the improvements in XML, I'd like to propose a obj-to-vals
>>    (the list/dict format suitable for write/create osv methods) and
>>    vals-to-xml methods to osv.osv objects. The code developed by me
>>    with Dukai's help is below.
>>
>>    http://paste-it.net/public/s29b2ca/
>>
>>    The methods are somewhat documented. Basically it converts the an
>>    osv.osv object into a simple and human-friendly xml format.
>>    For example, a res_partner object should give the expected output:
>>    <customer>
>>    <id>100</id>
>>    <name>Cliente Teste</name>
>>    <active>True</active>
>>    <credit_limit>1000.00</credit_limit>
>>    <address>
>>    <item>
>>    <id>150</id>
>>    <name>José da Silva</name>
>>    <type>default</type>
>>    <stree1>Av. Goiás, 100, Ap 10</stree1>
>>    <street2>Setor Central</street2>
>>    <city>Goiânia</city>
>>    <state_code>GO</state_code>
>>    <country_code>BR</country_code>
>>    <zip>74351018</zip>
>>    <email>joao_silva@xxxxxxxxx <mailto:joao_silva@xxxxxxxxx></email>
>>
>>    <phone>62-5555-0000</phone>
>>    <fax>62-5555-0001</fax>
>>    <mobile>62-5555-0002</mobile>
>>    </item>
>>    </address>
>>    </customer>
>>
>>
>>    All you need is a very simple binding declaring what you want in
>>    your xml. For the example above, you should provide:
>>
>>           binding = [
>>                   'id',
>>                   'name',
>>                   'active',
>>                   'credit_limit',
>>                   ('address','address', [
>>                           'id',
>>                           'name',
>>                           'type',
>>                           'street',
>>                           'street2',
>>                           'city',
>>                           ('state_id', 'state_code', 'code'),
>>                           ('country_id', 'country_code', 'code'),
>>                           'zip',
>>                           'email',
>>                           'phone',
>>                           'fax',
>>                           'mobile'
>>                       ]
>>                   )
>>           ]
>>
>>    By default, the serialization return a lxml object that can be
>>    further customized in code. The deserialization method accepts
>>    either a xml string or a lxml object so you can customize it prior
>>    to parsing.
>>
>>
>>
>>    _______________________________________________
>>    Mailing list: https://launchpad.net/~openerp-expert-framework
>>    <https://launchpad.net/%7Eopenerp-expert-framework>
>>
>>    Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
>>    <mailto:openerp-expert-framework@xxxxxxxxxxxxxxxxxxx>
>>
>>    Unsubscribe : https://launchpad.net/~openerp-expert-framework
>>    <https://launchpad.net/%7Eopenerp-expert-framework>
>>
>>    More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>