openerp-expert-framework team mailing list archive

[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