Issue 818046: Testcases account account_invoice (Closed)
DescriptionRemoved to http://codereview.appspot.com/2550042
Only tests/test_tryton.py should be reviewed.
The other files are unnecessary for later implementation, since the content of tests/test_tryton.py will be moved to the account and account_invoice module.
You can download the complete patch and store it into a folder named test_tryton under trytond/modules.
Change into trytond/modules/test_tryton/tests
and run:
$ sudo su tryton -c "python test_tryton.py"
Patch Set 1 #
Total comments: 16
Patch Set 2 : Fix issues and add tests #Patch Set 3 : new Version: more tests, fix issues #MessagesTotal messages: 9
http://codereview.appspot.com/818046/diff/1/12 File tests/test_tryton.py (right): http://codereview.appspot.com/818046/diff/1/12#newcode34 tests/test_tryton.py:34: def test0010createcompany(self): Why not rely on company creation of module company? http://codereview.appspot.com/818046/diff/1/12#newcode44 tests/test_tryton.py:44: }) missing context http://codereview.appspot.com/818046/diff/1/12#newcode57 tests/test_tryton.py:57: def test0020createfiscalyear2010(self): fiscalyear test should test date overlap and also different post move sequence. http://codereview.appspot.com/818046/diff/1/12#newcode62 tests/test_tryton.py:62: ], 0, 1, None, CONTEXT)[0] you can named args http://codereview.appspot.com/818046/diff/1/12#newcode79 tests/test_tryton.py:79: self.fiscalyear.create_period(cursor, USER, [fiscalyear_id], test also period_3
Sign in to reply to this message.
http://codereview.appspot.com/818046/diff/1/12 File tests/test_tryton.py (right): http://codereview.appspot.com/818046/diff/1/12#newcode34 tests/test_tryton.py:34: def test0010createcompany(self): On 2010/04/09 18:35:27, ced wrote: > Why not rely on company creation of module company? Yes, I want to do. But I collect some ideas for this: We could produce the demo database templates[1] for Tryton with the test scripts. With this, the templates are always 'fresh', and everyone can reproduce how the demo databases are made. In this step, another idea, I like to theme the demo data under a coherent topic, which also can be used for screen casts. ACME corp.[2] from several cartoons was my first aim. But now I found a better solution. The serial Futurama[3] which provides a space-story of a company with employees, customers and products. The Planet Express interplanetary delivery company is a delivery company which buy and sell and produce goods and services. There are resources[4] with pictures and so on under cc copyright[5]. But we really should discuss this on the mailing list. [1] http://www.tryton.org/de/demo.html [2] http://en.wikipedia.org/wiki/Acme_Corporation [3] http://en.wikipedia.org/wiki/Futurama [4] http://theinfosphere.org/List_of_products [5] http://creativecommons.org/licenses/by-sa/3.0/ http://codereview.appspot.com/818046/diff/1/12#newcode44 tests/test_tryton.py:44: }) On 2010/04/09 18:35:27, ced wrote: > missing context ok http://codereview.appspot.com/818046/diff/1/12#newcode57 tests/test_tryton.py:57: def test0020createfiscalyear2010(self): On 2010/04/09 18:35:27, ced wrote: > fiscalyear test should test date overlap and also different post move sequence. Yes, date overlap test is needed. What is the case for testing different post move sequence? http://codereview.appspot.com/818046/diff/1/12#newcode62 tests/test_tryton.py:62: ], 0, 1, None, CONTEXT)[0] On 2010/04/09 18:35:27, ced wrote: > you can named args ok. http://codereview.appspot.com/818046/diff/1/12#newcode79 tests/test_tryton.py:79: self.fiscalyear.create_period(cursor, USER, [fiscalyear_id], On 2010/04/09 18:35:27, ced wrote: > test also period_3 Don't understand?
Sign in to reply to this message.
http://codereview.appspot.com/818046/diff/1/12 File tests/test_tryton.py (right): http://codereview.appspot.com/818046/diff/1/12#newcode57 tests/test_tryton.py:57: def test0020createfiscalyear2010(self): On 2010/04/09 19:48:43, udono wrote: > On 2010/04/09 18:35:27, ced wrote: > > fiscalyear test should test date overlap and also different post move > sequence. > Yes, date overlap test is needed. What is the case for testing different post > move sequence? > There is a function check_post_move_sequence that ensure a sequence is only used once on fiscalyear records. http://codereview.appspot.com/818046/diff/1/12#newcode79 tests/test_tryton.py:79: self.fiscalyear.create_period(cursor, USER, [fiscalyear_id], On 2010/04/09 19:48:43, udono wrote: > On 2010/04/09 18:35:27, ced wrote: > > test also period_3 > > Don't understand? There is also acreate_period_3 function. And by the way, after calling you should verify if the periods are well created.
Sign in to reply to this message.
http://codereview.appspot.com/818046/diff/1/12 File tests/test_tryton.py (right): http://codereview.appspot.com/818046/diff/1/12#newcode44 tests/test_tryton.py:44: }) On 2010/04/09 19:48:43, udono wrote: > On 2010/04/09 18:35:27, ced wrote: > > missing context > ok Done. http://codereview.appspot.com/818046/diff/1/12#newcode57 tests/test_tryton.py:57: def test0020createfiscalyear2010(self): On 2010/04/09 18:35:27, ced wrote: > fiscalyear test should test date overlap and also different post move sequence. test date overlap Done. http://codereview.appspot.com/818046/diff/1/12#newcode62 tests/test_tryton.py:62: ], 0, 1, None, CONTEXT)[0] On 2010/04/09 18:35:27, ced wrote: > you can named args Done. http://codereview.appspot.com/818046/diff/1/12#newcode79 tests/test_tryton.py:79: self.fiscalyear.create_period(cursor, USER, [fiscalyear_id], On 2010/04/09 18:35:27, ced wrote: > test also period_3 Done.
Sign in to reply to this message.
Should I split the tests and put them in the appropriate test scrips for account and account_invoice? And then providing the diffs of the two test suites for review. Cheers Udo
Sign in to reply to this message.
On 2010/04/29 13:41:15, udono wrote: > Should I split the tests and put them in the appropriate test scrips for account > and account_invoice? And then providing the diffs of the two test suites for > review. > > Cheers Udo It is difficult to answer because it is tests for upper level before lower level one.
Sign in to reply to this message.
On 2010/04/29 20:53:40, ced wrote: > On 2010/04/29 13:41:15, udono wrote: > > Should I split the tests and put them in the appropriate test scrips for > account > > and account_invoice? And then providing the diffs of the two test suites for > > review. > > > > Cheers Udo > > It is difficult to answer because it is tests for upper level before lower level > one. The tests I provided are just testing some parts of the module api level. For testing Tryton before a release it is a big benefit for me, to know e.g. that invoice creation in general is working, the work flows are like expected, using different currencies. What you call upper level is for me upon the tests I provided. These upper level tests may test real business cases, like providing a year of accounting with tryton and check all amounts with a similar output from sage or quickbooks. For this kind of tests I have the same opinion like you, it is to early. First we need Framework/API/Module tests.
Sign in to reply to this message.
On 2010/04/30 08:45:33, udono wrote: > On 2010/04/29 20:53:40, ced wrote: > > On 2010/04/29 13:41:15, udono wrote: > > > Should I split the tests and put them in the appropriate test scrips for > > account > > > and account_invoice? And then providing the diffs of the two test suites for > > > review. > > > > > > Cheers Udo > > > > It is difficult to answer because it is tests for upper level before lower > level > > one. > The tests I provided are just testing some parts of the module api level. For > testing Tryton before a release it is a big benefit for me, to know e.g. that > invoice creation in general is working, the work flows are like expected, using > different currencies. > > What you call upper level is for me upon the tests I provided. These upper level > tests may test real business cases, like providing a year of accounting with > tryton and check all amounts with a similar output from sage or quickbooks. > > For this kind of tests I have the same opinion like you, it is to early. First > we need Framework/API/Module tests. Guys this kind of question should not go on codereview (it is only for code review :-) Please ask your general questions on tryton-dev.
Sign in to reply to this message.
|
