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 <[email protected]> > 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 <[email protected]<mailto: >> [email protected]>> 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>[email protected] <mailto:[email protected]></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 : [email protected] >> <mailto:[email protected]> >> >> Unsubscribe : https://launchpad.net/~openerp-expert-framework >> <https://launchpad.net/%7Eopenerp-expert-framework> >> >> More help : https://help.launchpad.net/ListHelp >> >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
