* Cédric Krier: " Re: [tryton-dev] Test and dependecies" (Tue, 13 May 2014 14:58:58 +0200):
> On 13 May 13:48, Mathias Behrle wrote: > > > There is a problem with the new tests added to purchase (see > > > http://tests.tryton.org/~test/postgresql.html). > > > The test fails when running with account_stock_continental because this > > > module add a constraint on product account stock. > > > > > > I wrote a patch: http://codereview.tryton.org/13311003 > > > but I'm not sure it is the right way to go. > > > An other possibility would be to remove the required of > > > account_stock_continental for bad design reason (there are still the > > > *_used which raise error message). > > > > > > What do you think? > > > > What about testing in tests/test_purchase.py, if module > > account_stock_continental is installed and just in case provide the needed > > values? > > Basicly it is similar solution to my patch but as explained in previous > email, Agreed. Similar, but not the same, as my proposal would have the benefit to be more clearly documented. > I think the issue is in the design of account_stock_continental. So we have to differentiate between several problems. The first one seems to be the design of account_stock_continental. If this issue can be solved by correcting the design, it is of course the way to go. The second issue is, that sooner or later there *can* be the case, where a dependent module will add constraints breaking a test in the former module. Just not implementing necessary constraints, because they could break tests, can not be the goal. For me, in a closed suite like the upstream modules are, tests could be made aware of other modules. Remains the problem depicted by Sergi: > So if i develop module XX (which is not part of core modules) and adds > another required field on product, I will need to add test in > test_purchase.py (which is a core module) in order to get the test pass, > so core modules must know about all the existing modules? IMHO this is > not the right way. I think, a possible solution could then be to include the test of the core module into the custom module, adapt it, and not to run the the test in the core module. Perhaps I am jumping too short here? -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
