IRC logs of #tryton for Tuesday, 2010-10-12 #tryton log beginning Tue Oct 12 00:00:01 CEST 2010
-!- zodman(~andres-va@ has joined #tryton01:02
-!- ikks(~ikks@ has joined #tryton04:56
-!- yangoon( has joined #tryton05:19
-!- zodman(~zodman@foresight/developer/zodman) has joined #tryton05:34
-!- zodman(~zodman@foresight/developer/zodman) has joined #tryton06:09
-!- mfladischer(~fladische@2001:470:1f0b:11df:b043:21ff:fe46:7793) has joined #tryton06:56
-!- vladimir_(~vladimir@ has joined #tryton07:04
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton08:05
-!- Timitos(~kp@ has joined #tryton08:23
-!- evernichon( has joined #tryton08:31
-!- evernichon( has left #tryton08:33
-!- eLBati(~elbati@ has joined #tryton08:46
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton09:18
-!- pepeu(~manuel@ has joined #tryton09:35
-!- bechamel( has joined #tryton09:36
-!- Red15(~red15@unaffiliated/red15) has joined #tryton10:02
-!- paepke( has joined #tryton10:44
-!- evernichon( has joined #tryton11:31
yangoonhi all11:37
yangoonI am just discussing with udono the design of application test layout via proteus11:37
yangoonmy notion is to split tests according to modules11:38
yangoonthis way several scripts could be referenced by others11:38
yangoonlike account depends from company, account_invoice depends from account etc.11:39
yangoonbut calendar could also reference company11:40
yangooni didn't look so far deep into proteus scripting. are there any pitfalls to expect? is it a reasonable design?11:41
udonoyangoon: for me proteus tests are test on user level functionality11:42
udonowhich is a kind of more abstract the module level tests11:43
yangoonudono: for user level totally agreed11:44
yangoondoesn't it make sense to provide a basic company test creating a company and an employee?11:44
yangoonbeing reused in other tests instead of duplicated?11:45
udonoyangoon: Iam not sure.11:46
udonoyangoon: I don't like to have a duplicated test count twice. I see no sense to have billions of tests in the end, which tests always the same functionality.11:50
bechameludono: yangoon : both vision are not incompatible11:51
bechamelfrom what I see udono talk about what the test should do and yangoon talk about how to layout stuffs11:52
udonobechamel: yes, agree11:52
yangooni don't like the idea to have one big test testing all11:53
udonoyangoon: maybe it is just that we should use helper functions for creating companies, invoices, ... and use them in a bigger test which tests the relationships?11:54
udonoyangoon: it is not one big test, but many 'bigger' tests then on module level.11:55
yangoonudono: sounds reasonable tome11:55
bechamelanother solution is to consider that if module A depends on module B he also know the state of the db at the end of the B test and then use those data to launch his tests11:56
bechamela bit like in xml we reference id's from other modules because we know them exactly11:57
udonobechamel: do you have an idea for a general design?11:57
bechamelbut this also means that changing a test in B can break test in A, but we will see it quickly11:58
bechameland IIRC the module import is deterministic, so it should works11:59
bechameludono: not really11:59
bechameludono: maybe you should start to write some tests for at least two module and see if it's feasible12:02
bechameland then launch a code review, before spending too much time on this, to gather ideas on a concrete example12:02
yangoonbechamel: udono I think we should just try, just wanted to know if there are general handicaps to expect12:03
udonoyangoon: bechamel: ok. A first impression pjs (paul) gave us with: found in
bechamelone of the issue to think about is how to show clearly what is the expected state at the end of the tests (like that people writing other test know what data they can use)12:07
bechamelbut "what is the expected state.." is obviously a part of the testing procedure12:08
-!- eLBati(~elbati@ has joined #tryton12:10
-!- Timitos(~kp@ has joined #tryton12:10
bechameludono, yangoon: and also writing at least two tests for two modules will show you what is common what is custom and a "test framework" will appear by itself12:13
-!- mfladischer(~fladische@2001:470:1f0b:11df:e88a:3cff:fe5f:b003) has joined #tryton12:14
yangoonbechamel: yes, will be best to just give it a try12:16
-!- eLBati(~elbati@ has joined #tryton13:38
cedkyangoon: be careful to not trying to write unittest with proteus14:46
-!- paepke( has joined #tryton14:47
-!- Gerald_E( has joined #tryton14:48
udonocedk: yangoon: Why not using unittest?15:02
yangoonudono: because we want to test business case15:02
yangooni would say it ia layer above15:03
udonoyangoon: so what should I use for 'test' if it works?15:03
yangoonudono: you mean to assert?15:04
udonoyangoon: using pythons assert only? without any output? Welcome to the stone age ;-)15:05
udonoWhat is the problem with a unittest suite?15:06
cedkudono: I mean writing unittest15:07
bechamelunit test (what you test) != unittest (the python module)15:07
cedkudono: I think the best will be to use docstring to write business case15:08
cedkudono: which is doctest15:09
udonocedk: why using doctest, when having a python concumber clone?15:11
udonoI think the BDD approaches are cumbersome.15:22
udonocedk: bechamel, yangoon: any guidance with this is welcome?15:26
-!- enlightx( has joined #tryton15:29
bechamelcedk: if you write doctest there will be nothing left in the function/method body15:30
bechameland imo python is enough expressive to make cumcumber clones unuseful15:32
udonoI would suggest to write a Tryton toolbox based on pyson. There you find methods like create_database(...), install_modules(), create_invoice, open_invoice, pay_invoice, ... Then using this methods for writing unittests, doctests, BDD stuff like lettuce, Pyccuracy, whatever. What do you think?15:34
bechameludono: create_database, install_modules: +115:37
bechameludono: create_invoice, open_invoice: I'm not sure if it's possible to provide generic helpers like that. But we should see with usage.15:39
udonobechamel: agree. It feels and looks like creating another API upon the given API from tryton.15:40
bechameludono: especialy with proteus that already automates default values, wizard, etc15:43
cedkbechamel: you don't need to have function to use doctest15:56
-!- pheller( has joined #tryton15:57
-!- zodman(~andres-va@foresight/developer/zodman) has joined #tryton15:58
bechamelcedk: and what is the advantage ? doctest is useful because there is the code to test just under it. Why do you want to write test with text while you can do it with python code ?15:59
cedkthe advantages are doctest will describe how to use proteus and the return values are tested in an expressive way15:59
cedkbechamel: because test in docstring of method are unittest15:59
cedkudono: I don't see the interest of writing a toolbox, proteus is already a toolbox16:00
bechameldoctest will describe how to use proteus > so put doctest inside porteus code, we are testing tryton not proteus16:00
bechamelcedk: already a toolbox > it's another problem16:01
cedkbechamel: can not put doctest inside proteus16:01
bechamelit's not a reason  to put them on other places :)16:03
udonocedk: there is no need to put doctest into proteus.16:03
cedkbechamel: we don't test proteus (already done), we test Tryton16:03
cedkudono: I don't want16:03
udonocedk: I said: There is _no_ need to put doctest into proteus.16:04
bechamelobviously something like install_module() should be written somewhere ..16:04
cedkbechamel: why?16:05
bechamelyou plan to install modules inside docstring ?16:05
cedkbechamel: stop talking about docstring16:05
udonocedk: and I agree, proteus is the toolbox. Method install_modules can be put into proteus as another tool.16:05
-!- zodman(~andres-va@ has joined #tryton16:06
cedkudono: installing module is only 2 lines16:07
bechamelcedk: you insist about using docstring16:07
cedkbechamel: no doctest16:07
bechamelso re-read my comments with s/docstring/doctest/16:08
cedkudono: Module.button_install([ for x in Module.find([('name', '=', module_name)])]); Wizard('ir.module.module.install_upgrade').execute('start')16:09
udonocedk: with this coding style trytond is a one-liner, too ;-)16:09
cedkudono: ok 3 lines16:09
udonocedk: 33% inacurate ;-)16:10
cedkbechamel: so why don't you want to use doctest ?16:10
udonocedk: what about and even more critical:
cedkudono: the guys say: "don't use doctest for unittest"16:11
cedkudono: we use unittest for unittest16:12
udonocedk: read the article16:12
cedkhere we talk about global test with scenario like making a sale then shipping it and invoice it etc.16:12
bechamellet's take the example you gave (on wikipedia), I can write it:  a,b = 1,2; assert a==b, I don't see how adding ">>>" and "..." is better16:13
udonocedk: yes, and why make it harder to write these tests then other tests?16:13
cedkbechamel: the example on wikipedia is simple, I give it to show it is possible to write doctest outside method docstring16:14
cedkudono: why is it harder?16:14
cedkudono: the articles you give say that doctest is good for acceptance test16:15
cedkudono: and we are looking to write acceptance test16:15
bechamelcedk: longer test will became a nightmare with >>> and ... and different level of indentation that will be in a text that the text editor will not indent automaticaly16:15
udonocedk: because we need to write/maintain prose texts between the doctests.16:15
cedkbechamel: no, because we will not have that with proteus16:15
-!- gremly(~gremly@ has joined #tryton16:16
cedkbechamel: the advantange will be to test in an simple way the result (like complete invoice fields)16:16
bechamelcedk: so it's my turn to ask you the question: what's the problem of writing test in python ??16:16
cedkudono: so write generic sentence16:17
udonocedk: what makes doctest simpler thn unittest in this case?16:17
cedkbechamel: because you can write only one long test method16:18
cedkbechamel: and finally you will have the same then with doctest but with comments16:18
udonocedk: generic sentences are better catched as comment. The python test code needs to be simple, I find.16:18
cedkbechamel: and the testing fo result is more verbose then with doctest16:18
bechamelcedk: python code also support comment :)16:19
bechameland finally you will have the same then with doctest > no, my text editor is much more better at editing code that editing strings16:20
cedkbechamel: your text editor is not good at writing ReST ?16:24
cedkbechamel: you did not catch that testing result will be simplier with doctest16:24
bechameldoctest are just code inside string and imo there are no advantage over writing code directly16:25
cedkbechamel: no because there is test on each line for the result16:26
bechamelI made a test with doctest and traceback are also incorrect16:26
cedkbechamel: and you must not write it as a comment16:27
cedkbechamel: link?16:27
bechamelcedk: just try to put a syntax error on a docstring, you receive "unexpected EOF while parsing"16:28
cedkbechamel: code to test?16:29
bechamelcedk:, you have to save the file as to make it wokr16:30
bechamelcedk: the error is because a space is missing before ]16:32
bechamelbut if you remove completly this line you will get the "unexpected EOF" error16:32
cedkbechamel: and?16:34
bechameland I don't see how it's easier to write this that python code16:34
cedkbechamel: it is not more complicated then Python16:34
bechamelcedk: yes it is16:34
bechamelno editor support (auto-indent, coloration), extra characters (>>> and ...)16:35
udonocedk: there are other problems with doctests: look for "Doctest is a mini-language with ugly corners and outright bugs."16:35
cedkbechamel: with unittest you will need to write a lot of self.assert_ or self.assertEqual etc.16:35
cedkudono: I pretty sure it is not a problem for the kind of test we want to write16:36
bechamelcedk: 1) it's not a problem 2) you just tell us that because of proteus tests will be short 3) it's not unit test so imo it's ok to create lot's of records and at the just do something like "assert total == 1"16:37
cedkbechamel: no need to create a lot of records16:40
cedktest will describe a scenario16:40
cedklike in
bechamelcedk: if I want to test an invoice I have at least : customer (+ category), payment term (+line), products (+category), taxes, invoice lines, etc. And the final test will be to check the amounts and dates of the generated acouting moves16:42
bechameland obviously the test will also generate a lot of variant mixing taxes combinations, different payment terms, etc16:44
udonocedk: bechamel: Is it a way, to just start writing tests for Tryton 1.8? We simply use unittest, because we all are experienced enough with this, for now. After release 1.8 we can't take a deep look, if the approach is sufficient enough for us. And for 1.10 we can discuss the final design for higherlevel tests. When we change the design, we will not loose so much, since unittest and doctest are quite similar, when unittest is commented16:45
cedkbechamel: it is not *unittest*16:47
udono*After release 1.8 we can take a deep look16:47
cedkbechamel: you just test scenario16:47
udonocedk: yes, and one scenario is one unit of test.16:48
cedkbechamel: if the tax computation method are "unittested" completly there is no need to make scenario for every cases16:48
bechamelcedk: so what will be tested ??16:48
udonocedk: I do not want to produce billions of similar testcases, when creating a product.16:48
cedkbechamel: the combination of all16:49
cedkudono: of course and there is no need16:49
bechamelcedk: and because we test combination, there is no need of creating records ?16:49
cedkbechamel: just somes16:50
udonoWhat does in mean 'creating of records'?16:50
cedkbechamel: you make a scenario that does like a complete installation and configuration of Tryton and also some operations16:50
bechamelthis conversation is pointless as long as we don't know what those test will do16:50
cedkbechamel: scenario is clear16:51
bechamelcedk: example ?16:51
cedkbechamel: you make a scenario that does like a complete installation and configuration of Tryton and also some operations16:52
cedkbechamel: what do you do when you test a new module ?16:52
bechamelcedk: I create a lot of records ...16:53
udonocedk: For different scenarios we need different test suites/databases16:53
bechameland I test one or two result (stock level, invoice amount, etc)16:53
udonoE.g. I need to have one scenario creates 100000 Invoices and 100000 Payments in account_statement to test later the client performance by hand...16:55
udonoOther scenarios I need to test are given in:
udonoAnother scenario is a real world company setup which tests all installed modules and functionalities. This could be used to create the demo databases on tryton.org16:58
cedkudono: a scenario must create a database, install module, configure and make some operations17:01
udonocedk: yes, that's what I say. Each scenario needs own database/module configuration.17:02
bechamelcedk: do you plan to repeat all those steps in each docstrings ?17:04
cedkof course all those scenarii are not completly useful if there is no unittest17:04
udonocedk: it is usefull because it tells me, that the tested functionality will work.17:05
udonocedk: but you are right, on modul level there are a lot of todos in question of testing17:05
cedkbechamel: there will not be a lot repeated17:07
udonocedk: Tarec Ziade suggests in Expert Python Programming:
cedkudono: like I do :-)17:17
bechamel"They cannot be taken and run in a simple prompt" > this is so true,  I'm always mad when i have to reformat docstring code before using it ..17:18
bechamelcedk: btw, you told that testing taxes should be done with unittesting, so imo we should spend time on unit test before running to use proteus17:20
cedkbechamel: it is what I said since 2 years17:21
cedkbechamel: this doesn't prevent udono to write scenarii17:21
bechamelso we spend the afternoon talking about stuff that are not really needed now17:21
cedkwith unittest we don't test a lot module interaction like with scenarii17:22
cedkbechamel: no, because udono want to write scenarii for testing Tryton for the coming release17:22
cedklike that his work will be not lost for the next release17:22
udonocedk: you got it. I just don't like to test stuff like in each release. It is too boring in the long run.17:23
bechamelcedk: so it's up to him to choose the tool to write their tests :D17:24
phellerwhat an enjoyable conversation to read :-)17:24
yangooncedk: where (in which fiels) would those doctests reside?17:25
bechamelpheller: did you bring your pop-corn ? ;)17:26
udonopheller: :-D17:28
Timitospheller: do not put more fuel to the fire ;-)17:28
cedkyangoon: I guess in one Rest file17:28
-!- evernichon( has left #tryton17:28
cedkbechamel: of course, udono can use the tools he wants but he was asking our opinions17:29
phellerI'm curious, why not use cucumber or something else for scenario testing?17:35
cedkpheller: it doesn't work :-)17:35
phellerhow about one of the python equivalents -- freshen or lettuce ?17:35
cedkpheller: I mean the concept doesn't work17:35
phellerah, ok17:36
cedkpheller: because the scenario should be written by end-users but generally they can not write good scenario17:36
cedkbechamel: did you find the post about cucumber?17:37
pheller... and you think that they will be better able to write the test in python within a docstring?17:37
bechamelIMO nothing beats python itself (neither doctest nor cumcumber)17:41
phellercedk: I suppose if the argument is that end-users can't write tests at all (no matter what language), then my question is -- why simplify with doctests when unittests will allow the developer to continue using their editor (with syntax highlighting, introspection, etc)17:41
pheller... though I wonder if an adaptation of the "module_recorder" concept might be useful to generate scenario tests from direct interaction with the client....17:42
cedkpheller: doctest is not simplify17:45
cedkpheller: it is one of many testing framework17:45
cedkpheller: I find it suite well the requirement of scenario17:46
phellercedk: ok, simplified in the fact that one does not write an assertion for the result.  It is inferred based upon the result of the statement.17:46
phellercedk: but, perhaps the best test of this --- why not write some examples in this manner and share them on the list?17:46
-!- enlightx( has joined #tryton18:53
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton18:55
-!- drupin(~drupin@unaffiliated/drupin) has joined #tryton18:57
-!- chrue( has joined #tryton19:19
-!- plantian( has joined #tryton19:20
-!- paepke( has left #tryton19:44
yangooncedk: could you please have a short look on
yangoonsorting of translation seems to be way lost20:37
yangoonshould I push nevertheless?20:38
cedkyangoon: that is very strange21:50
cedkyangoon: wait I will check21:50
yangooncedk: remembers me
cedkyangoon: should not be linked21:52
-!- eLBati(~elbati@ has joined #tryton21:56
yangooncedk: btw we had no bugfix release for account 1.6 since 4 months, for trytond 1.6 since 2 months21:56
yangoonany plans for this?21:56
cedkyangoon: I will do with 1.821:57
yangooncedk: great21:57
yangooncedk: btw, last btw btw hopefully;): shows paths like 1.6/neso/trytond22:02
cedkyangoon: don't understand22:04
yangoon1.6/neso/trytond is a virtual repos and basically a duplicate of 1.6/trytond22:05
yangoonimportant for hgnested, but not for webinterface22:06
cedkyangoon: fixed22:11
cedkyangoon: with which database backend are you translating?22:21
yangooncedk: this was with neso22:21
cedkyangoon: so SQLite22:21
cedkyangoon: I think the sort is different than with PostgreSQL22:21
cedkyangoon: I think we could improve it by sorting in Python22:23
-!- jcnorman( has joined #tryton22:26
jcnormanI've used openerp for some time, and am trying tryton from a source install.  The client is not seeing the server on port 8070, even though the server says it's listening on 8070 and portscan shows 8070 active - any suggestions?22:27
cedkjcnorman: are you on the same host?22:30
lem0najcnorman: i recieved the same error when can not connect to the database22:31
jcnormanyes, i am22:32
yangooncedk: I must admit that sorting of sqlite seems more adequate in this case22:33
jcnormanI'm starting trytond as user jim - checking to see if that's a valid postgresql user22:33
yangooncomparing line 235 and 248 on
yangoonseems to me not correctly sorted22:34
yangoonon the left hand22:34
cedkyangoon: the sort was done on type, name, src, res_id22:35
yangoon235 field,"ir.rule,field    236 field,"   248 field,"ir.rule,operand22:36
yangooncedk: it doesn't handle point or comma22:37
jcnormanStill no joy with seeing server - any suggestions?22:37
cedkjcnorman: how is the login window?22:38
jcnormanfor database, shows Could not connect to server!22:38
cedkjcnorman: which server name are you using?22:39
jcnormanI've tried both localhost:8070 and
yangoonjcnorman: could you try with for interface in trytond.conf22:41
jcnormanWill do - I currently just have interface=22:41
jcnormanstill no joy22:43
lem0najcnorman: check permissions in pg_hba.conf22:43
yangoonjcnorman: please paste the output of trytond -v22:44
jcnormanOK - but ti's been working with openerp for a long time22:44
lem0najcnorman: can you connect with this user from psql ?22:44
jcnormanwill try22:45
-!- plantian( has joined #tryton22:45
jcnormanI can connect with psql22:46
jcnormanwhen I configured openerp, I setup a system user for openerp, and had that user own all DBs - do you suggest using tryton as a system user, owning DBs?22:47
cedkjcnorman: yes22:50
jcnormanwhich pastebin is in use?22:50
lem0najcnorman: i think that trytond is the default db user if nothing else specified in config file22:51
cedkjcnorman: the one you prefer :-)22:51
cedklem0na: no it use the unix user that is running trytond22:51
jcnormanthe conf file is
yangooncedk: thx, will try22:55
cedkjcnorman: and the server log?22:56
jcnormanOK - just a moment22:57
yangooncedk: already on
jcnormanserver log is:
yangoonjcnorman: if this is the most recent log, the server seems tobe connected to the databse22:59
jcnormanRight, but the client is not seeing the server23:00
jcnormanom 807023:00
udonojcnorman: hi, it seems the database connection.23:02
cedkjcnorman: it seems that PostgreSQL requires a password for connection23:03
jcnormanOK, whgere is that supplied?23:03
lem0na[Tue Oct 12 16:36:48 2010] INFO:database:connect to "fairmont"23:03
udonojcnorman: the user which runs trytond must be able to connect to the database with the given passwordin line 35 of
lem0nai think you have to set trusted conenction23:03
lem0naat least for this database23:04
lem0naotherwise  supply password23:04
udonolem0na: jcnorman ... not to forget to use a more secure database connection later in production environment ...23:05
-!- jcnorman( has joined #tryton23:08
jcnormanSorry - had to reboot - clicked on a link provided in irc and it started opening windows like crazy - couldn't stop it23:09
jcnormanI've also tries logging in as user tryton with no joy.23:11
lem0najcnorman: do you start trytond with command parammeters?23:13
jcnormansorry - that's configuring db user as tryton23:14
lem0nainteresting  - i see command param for db_user but not for db_pass23:18
lem0najcnorman: can you add in pg_hba trusted connection for database fairmont - just for the test23:19
jcnormandatabase fairmont doesn't yet exist23:24
lem0najcnorman: second option is to start trytond with --config=CONFIG where CONFIG is path to some config file with db_user and db_password23:24
jcnormanI'm making progress - now have permission denied to create database - need to change grants on user tryton23:28
jcnormanJOY!! JOY!!23:29
jcnormanThanks to all!23:30
jcnormanIs there an easy way to get all modules?23:32
yangoonlook for hgnested23:33
jcnormanOK - thanks23:33
yangoonACTION afk23:33
-!- lem0na(~lem0na@ has joined #tryton23:41
jcnormanSorry, but I've gotten hgnested (both 0.1 and 0.2) install fails with (see
jcnormanI had hg version 1.4 - supported for Ubuntu 10.04.  removed that, and still have the problem23:47
jcnormanIt seems to be failing with install of hg 1.6.423:48
cedkjcnorman: you must update mercurial >= 1.5.023:49
jcnormanOk - I'll try the hg site23:49
cedkjcnorman: otherwise you miss Python headers to compile mercurial23:50

Generated by 2.11.0 by Marius Gedminas - find it at!