| chat.freenode.net #tryton log beginning Tue Oct 12 00:00:01 CEST 2010 | ||
| 2010-10-12 01:02 -!- zodman(~andres-va@200.67.176.253) has joined #tryton | ||
| 2010-10-12 04:56 -!- ikks(~ikks@190.158.112.13) has joined #tryton | ||
| 2010-10-12 05:19 -!- yangoon(~mathiasb@p549F6406.dip.t-dialin.net) has joined #tryton | ||
| 2010-10-12 05:34 -!- zodman(~zodman@foresight/developer/zodman) has joined #tryton | ||
| 2010-10-12 06:09 -!- zodman(~zodman@foresight/developer/zodman) has joined #tryton | ||
| 2010-10-12 06:56 -!- mfladischer(~fladische@2001:470:1f0b:11df:b043:21ff:fe46:7793) has joined #tryton | ||
| 2010-10-12 07:04 -!- vladimir_(~vladimir@213.151.246.136) has joined #tryton | ||
| 2010-10-12 08:05 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton | ||
| 2010-10-12 08:23 -!- Timitos(~kp@88.217.184.172) has joined #tryton | ||
| 2010-10-12 08:31 -!- evernichon(~evernicho@i01m-62-35-143-35.d4.club-internet.fr) has joined #tryton | ||
| 2010-10-12 08:33 -!- evernichon(~evernicho@i01m-62-35-143-35.d4.club-internet.fr) has left #tryton | ||
| 2010-10-12 08:46 -!- eLBati(~elbati@94.164.122.122) has joined #tryton | ||
| 2010-10-12 09:18 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton | ||
| 2010-10-12 09:35 -!- pepeu(~manuel@201.155.193.192) has joined #tryton | ||
| 2010-10-12 09:36 -!- bechamel(~user@chimie-prtx11.scf.fundp.ac.be) has joined #tryton | ||
| 2010-10-12 10:02 -!- Red15(~red15@unaffiliated/red15) has joined #tryton | ||
| 2010-10-12 10:44 -!- paepke(~paepke@p4FEB18EF.dip0.t-ipconnect.de) has joined #tryton | ||
| 2010-10-12 11:31 -!- evernichon(~evernicho@i01m-62-35-143-35.d4.club-internet.fr) has joined #tryton | ||
| 2010-10-12 11:37 <yangoon> hi all | ||
| 2010-10-12 11:37 <yangoon> I am just discussing with udono the design of application test layout via proteus | ||
| 2010-10-12 11:38 <yangoon> my notion is to split tests according to modules | ||
| 2010-10-12 11:38 <yangoon> this way several scripts could be referenced by others | ||
| 2010-10-12 11:39 <yangoon> like account depends from company, account_invoice depends from account etc. | ||
| 2010-10-12 11:40 <yangoon> but calendar could also reference company | ||
| 2010-10-12 11:41 <yangoon> i didn't look so far deep into proteus scripting. are there any pitfalls to expect? is it a reasonable design? | ||
| 2010-10-12 11:42 <udono> yangoon: for me proteus tests are test on user level functionality | ||
| 2010-10-12 11:43 <udono> which is a kind of more abstract the module level tests | ||
| 2010-10-12 11:43 <udono> s/the/then/ | ||
| 2010-10-12 11:44 <yangoon> udono: for user level totally agreed | ||
| 2010-10-12 11:44 <yangoon> doesn't it make sense to provide a basic company test creating a company and an employee? | ||
| 2010-10-12 11:45 <yangoon> being reused in other tests instead of duplicated? | ||
| 2010-10-12 11:46 <udono> yangoon: Iam not sure. | ||
| 2010-10-12 11:50 <udono> yangoon: 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. | ||
| 2010-10-12 11:51 <bechamel> udono: yangoon : both vision are not incompatible | ||
| 2010-10-12 11:52 <bechamel> from what I see udono talk about what the test should do and yangoon talk about how to layout stuffs | ||
| 2010-10-12 11:52 <udono> bechamel: yes, agree | ||
| 2010-10-12 11:52 <yangoon> agreed | ||
| 2010-10-12 11:53 <yangoon> i don't like the idea to have one big test testing all | ||
| 2010-10-12 11:54 <udono> yangoon: 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? | ||
| 2010-10-12 11:55 <udono> yangoon: it is not one big test, but many 'bigger' tests then on module level. | ||
| 2010-10-12 11:55 <yangoon> udono: sounds reasonable tome | ||
| 2010-10-12 11:56 <bechamel> another 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 tests | ||
| 2010-10-12 11:57 <bechamel> a bit like in xml we reference id's from other modules because we know them exactly | ||
| 2010-10-12 11:57 <udono> bechamel: do you have an idea for a general design? | ||
| 2010-10-12 11:58 <bechamel> but this also means that changing a test in B can break test in A, but we will see it quickly | ||
| 2010-10-12 11:59 <bechamel> and IIRC the module import is deterministic, so it should works | ||
| 2010-10-12 11:59 <bechamel> udono: not really | ||
| 2010-10-12 12:02 <bechamel> udono: maybe you should start to write some tests for at least two module and see if it's feasible | ||
| 2010-10-12 12:02 <bechamel> and then launch a code review, before spending too much time on this, to gather ideas on a concrete example | ||
| 2010-10-12 12:03 <yangoon> bechamel: udono I think we should just try, just wanted to know if there are general handicaps to expect | ||
| 2010-10-12 12:06 <udono> yangoon: bechamel: ok. A first impression pjs (paul) gave us with: https://bugs.tryton.org/roundup/file933/test.py found in https://bugs.tryton.org/roundup/issue1712 | ||
| 2010-10-12 12:07 <bechamel> one 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) | ||
| 2010-10-12 12:08 <bechamel> but "what is the expected state.." is obviously a part of the testing procedure | ||
| 2010-10-12 12:10 -!- eLBati(~elbati@94.165.2.6) has joined #tryton | ||
| 2010-10-12 12:10 -!- Timitos(~kp@88.217.184.172) has joined #tryton | ||
| 2010-10-12 12:13 <bechamel> udono, 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 itself | ||
| 2010-10-12 12:14 -!- mfladischer(~fladische@2001:470:1f0b:11df:e88a:3cff:fe5f:b003) has joined #tryton | ||
| 2010-10-12 12:16 <yangoon> bechamel: yes, will be best to just give it a try | ||
| 2010-10-12 13:38 -!- eLBati(~elbati@94.164.142.38) has joined #tryton | ||
| 2010-10-12 14:46 <cedk> yangoon: be careful to not trying to write unittest with proteus | ||
| 2010-10-12 14:47 -!- paepke(~paepke@p4FEB0757.dip0.t-ipconnect.de) has joined #tryton | ||
| 2010-10-12 14:48 -!- Gerald_E(~quassel@ip-240-3.pel.cz) has joined #tryton | ||
| 2010-10-12 15:02 <udono> cedk: yangoon: Why not using unittest? | ||
| 2010-10-12 15:02 <yangoon> udono: because we want to test business case | ||
| 2010-10-12 15:03 <yangoon> i would say it ia layer above | ||
| 2010-10-12 15:03 <udono> yangoon: so what should I use for 'test' if it works? | ||
| 2010-10-12 15:04 <yangoon> udono: you mean to assert? | ||
| 2010-10-12 15:05 <udono> yangoon: using pythons assert only? without any output? Welcome to the stone age ;-) | ||
| 2010-10-12 15:06 <udono> What is the problem with a unittest suite? | ||
| 2010-10-12 15:07 <cedk> udono: I mean writing unittest | ||
| 2010-10-12 15:07 <bechamel> unit test (what you test) != unittest (the python module) | ||
| 2010-10-12 15:08 <cedk> udono: I think the best will be to use docstring to write business case | ||
| 2010-10-12 15:09 <cedk> udono: which is doctest | ||
| 2010-10-12 15:11 <udono> cedk: why using doctest, when having a python concumber clone? | ||
| 2010-10-12 15:22 <udono> I think the BDD approaches are cumbersome. | ||
| 2010-10-12 15:23 <udono> http://bemusement.org/diary/2008/October/24/more-doctest-problems | ||
| 2010-10-12 15:26 <udono> cedk: bechamel, yangoon: any guidance with this is welcome? | ||
| 2010-10-12 15:29 -!- enlightx(~enlightx@static-217-133-61-144.clienti.tiscali.it) has joined #tryton | ||
| 2010-10-12 15:30 <bechamel> cedk: if you write doctest there will be nothing left in the function/method body | ||
| 2010-10-12 15:32 <bechamel> and imo python is enough expressive to make cumcumber clones unuseful | ||
| 2010-10-12 15:34 <udono> I 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? | ||
| 2010-10-12 15:37 <bechamel> udono: create_database, install_modules: +1 | ||
| 2010-10-12 15:39 <bechamel> udono: create_invoice, open_invoice: I'm not sure if it's possible to provide generic helpers like that. But we should see with usage. | ||
| 2010-10-12 15:40 <udono> bechamel: agree. It feels and looks like creating another API upon the given API from tryton. | ||
| 2010-10-12 15:43 <bechamel> udono: especialy with proteus that already automates default values, wizard, etc | ||
| 2010-10-12 15:45 <udono> yes | ||
| 2010-10-12 15:56 <cedk> bechamel: you don't need to have function to use doctest | ||
| 2010-10-12 15:57 <cedk> http://en.wikipedia.org/wiki/Doctest#Example_2:_doctests_embedded_in_a_README.txt_file | ||
| 2010-10-12 15:57 -!- pheller(~pheller@c1fw237.constantcontact.com) has joined #tryton | ||
| 2010-10-12 15:58 -!- zodman(~andres-va@foresight/developer/zodman) has joined #tryton | ||
| 2010-10-12 15:59 <bechamel> cedk: 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 ? | ||
| 2010-10-12 15:59 <cedk> the advantages are doctest will describe how to use proteus and the return values are tested in an expressive way | ||
| 2010-10-12 15:59 <cedk> bechamel: because test in docstring of method are unittest | ||
| 2010-10-12 16:00 <cedk> udono: I don't see the interest of writing a toolbox, proteus is already a toolbox | ||
| 2010-10-12 16:00 <bechamel> doctest will describe how to use proteus > so put doctest inside porteus code, we are testing tryton not proteus | ||
| 2010-10-12 16:01 <bechamel> cedk: already a toolbox > it's another problem | ||
| 2010-10-12 16:01 <cedk> bechamel: can not put doctest inside proteus | ||
| 2010-10-12 16:03 <bechamel> it's not a reason to put them on other places :) | ||
| 2010-10-12 16:03 <udono> cedk: there is no need to put doctest into proteus. | ||
| 2010-10-12 16:03 <cedk> bechamel: we don't test proteus (already done), we test Tryton | ||
| 2010-10-12 16:03 <cedk> udono: I don't want | ||
| 2010-10-12 16:04 <udono> cedk: I said: There is _no_ need to put doctest into proteus. | ||
| 2010-10-12 16:04 <bechamel> obviously something like install_module() should be written somewhere .. | ||
| 2010-10-12 16:05 <cedk> bechamel: why? | ||
| 2010-10-12 16:05 <bechamel> you plan to install modules inside docstring ? | ||
| 2010-10-12 16:05 <cedk> bechamel: stop talking about docstring | ||
| 2010-10-12 16:05 <udono> cedk: and I agree, proteus is the toolbox. Method install_modules can be put into proteus as another tool. | ||
| 2010-10-12 16:06 -!- zodman(~andres-va@200.67.176.253) has joined #tryton | ||
| 2010-10-12 16:07 <cedk> udono: installing module is only 2 lines | ||
| 2010-10-12 16:07 <bechamel> cedk: you insist about using docstring | ||
| 2010-10-12 16:07 <cedk> bechamel: no doctest | ||
| 2010-10-12 16:07 <cedk> bechamel: http://en.wikipedia.org/wiki/Doctest#Example_2:_doctests_embedded_in_a_README.txt_file | ||
| 2010-10-12 16:08 <bechamel> so re-read my comments with s/docstring/doctest/ | ||
| 2010-10-12 16:09 <cedk> udono: Module.button_install([x.id for x in Module.find([('name', '=', module_name)])]); Wizard('ir.module.module.install_upgrade').execute('start') | ||
| 2010-10-12 16:09 <udono> cedk: with this coding style trytond is a one-liner, too ;-) | ||
| 2010-10-12 16:09 <cedk> udono: ok 3 lines | ||
| 2010-10-12 16:10 <udono> cedk: 33% inacurate ;-) | ||
| 2010-10-12 16:10 <cedk> bechamel: so why don't you want to use doctest ? | ||
| 2010-10-12 16:11 <udono> cedk: what about http://bemusement.org/diary/2008/October/23/narrative-tests and even more critical: http://bemusement.org/diary/2008/October/24/more-doctest-problems | ||
| 2010-10-12 16:11 <cedk> udono: the guys say: "don't use doctest for unittest" | ||
| 2010-10-12 16:12 <cedk> udono: we use unittest for unittest | ||
| 2010-10-12 16:12 <udono> cedk: read the article | ||
| 2010-10-12 16:12 <cedk> here we talk about global test with scenario like making a sale then shipping it and invoice it etc. | ||
| 2010-10-12 16:13 <bechamel> let'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 better | ||
| 2010-10-12 16:13 <udono> cedk: yes, and why make it harder to write these tests then other tests? | ||
| 2010-10-12 16:14 <cedk> bechamel: the example on wikipedia is simple, I give it to show it is possible to write doctest outside method docstring | ||
| 2010-10-12 16:14 <cedk> udono: why is it harder? | ||
| 2010-10-12 16:15 <cedk> udono: the articles you give say that doctest is good for acceptance test | ||
| 2010-10-12 16:15 <cedk> udono: and we are looking to write acceptance test | ||
| 2010-10-12 16:15 <bechamel> cedk: 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 automaticaly | ||
| 2010-10-12 16:15 <udono> cedk: because we need to write/maintain prose texts between the doctests. | ||
| 2010-10-12 16:15 <cedk> bechamel: no, because we will not have that with proteus | ||
| 2010-10-12 16:16 -!- gremly(~gremly@200.106.202.91) has joined #tryton | ||
| 2010-10-12 16:16 <cedk> bechamel: the advantange will be to test in an simple way the result (like complete invoice fields) | ||
| 2010-10-12 16:16 <bechamel> cedk: so it's my turn to ask you the question: what's the problem of writing test in python ?? | ||
| 2010-10-12 16:17 <cedk> udono: so write generic sentence | ||
| 2010-10-12 16:17 <udono> cedk: what makes doctest simpler thn unittest in this case? | ||
| 2010-10-12 16:18 <cedk> bechamel: because you can write only one long test method | ||
| 2010-10-12 16:18 <cedk> bechamel: and finally you will have the same then with doctest but with comments | ||
| 2010-10-12 16:18 <udono> cedk: generic sentences are better catched as comment. The python test code needs to be simple, I find. | ||
| 2010-10-12 16:18 <cedk> bechamel: and the testing fo result is more verbose then with doctest | ||
| 2010-10-12 16:19 <bechamel> cedk: python code also support comment :) | ||
| 2010-10-12 16:20 <bechamel> and finally you will have the same then with doctest > no, my text editor is much more better at editing code that editing strings | ||
| 2010-10-12 16:24 <cedk> bechamel: your text editor is not good at writing ReST ? | ||
| 2010-10-12 16:24 <cedk> bechamel: you did not catch that testing result will be simplier with doctest | ||
| 2010-10-12 16:25 <bechamel> doctest are just code inside string and imo there are no advantage over writing code directly | ||
| 2010-10-12 16:26 <cedk> bechamel: no because there is test on each line for the result | ||
| 2010-10-12 16:26 <bechamel> I made a test with doctest and traceback are also incorrect | ||
| 2010-10-12 16:27 <cedk> bechamel: and you must not write it as a comment | ||
| 2010-10-12 16:27 <cedk> bechamel: link? | ||
| 2010-10-12 16:28 <bechamel> cedk: just try to put a syntax error on a docstring, you receive "unexpected EOF while parsing" | ||
| 2010-10-12 16:29 <cedk> bechamel: code to test? | ||
| 2010-10-12 16:30 <bechamel> cedk: http://paste.pocoo.org/show/274499/, you have to save the file as test.py to make it wokr | ||
| 2010-10-12 16:30 <bechamel> *work | ||
| 2010-10-12 16:32 <bechamel> cedk: the error is because a space is missing before ] | ||
| 2010-10-12 16:32 <bechamel> but if you remove completly this line you will get the "unexpected EOF" error | ||
| 2010-10-12 16:34 <cedk> bechamel: and? | ||
| 2010-10-12 16:34 <bechamel> and I don't see how it's easier to write this that python code | ||
| 2010-10-12 16:34 <cedk> bechamel: it is not more complicated then Python | ||
| 2010-10-12 16:34 <bechamel> cedk: yes it is | ||
| 2010-10-12 16:35 <bechamel> no editor support (auto-indent, coloration), extra characters (>>> and ...) | ||
| 2010-10-12 16:35 <udono> cedk: there are other problems with doctests: http://bemusement.org/diary/2008/October/24/more-doctest-problems look for "Doctest is a mini-language with ugly corners and outright bugs." | ||
| 2010-10-12 16:35 <cedk> bechamel: with unittest you will need to write a lot of self.assert_ or self.assertEqual etc. | ||
| 2010-10-12 16:36 <cedk> udono: I pretty sure it is not a problem for the kind of test we want to write | ||
| 2010-10-12 16:37 <bechamel> cedk: 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" | ||
| 2010-10-12 16:40 <cedk> bechamel: no need to create a lot of records | ||
| 2010-10-12 16:40 <cedk> test will describe a scenario | ||
| 2010-10-12 16:41 <cedk> like in http://spreadsheets.google.com/ccc?key=tU28D4LEDJMkWmgMWfmbgXg | ||
| 2010-10-12 16:42 <bechamel> cedk: 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 moves | ||
| 2010-10-12 16:44 <bechamel> and obviously the test will also generate a lot of variant mixing taxes combinations, different payment terms, etc | ||
| 2010-10-12 16:45 <udono> cedk: 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 commented | ||
| 2010-10-12 16:47 <cedk> bechamel: it is not *unittest* | ||
| 2010-10-12 16:47 <udono> *After release 1.8 we can take a deep look | ||
| 2010-10-12 16:47 <cedk> bechamel: you just test scenario | ||
| 2010-10-12 16:48 <udono> cedk: yes, and one scenario is one unit of test. | ||
| 2010-10-12 16:48 <cedk> bechamel: if the tax computation method are "unittested" completly there is no need to make scenario for every cases | ||
| 2010-10-12 16:48 <bechamel> cedk: so what will be tested ?? | ||
| 2010-10-12 16:48 <udono> cedk: I do not want to produce billions of similar testcases, when creating a product. | ||
| 2010-10-12 16:49 <cedk> bechamel: the combination of all | ||
| 2010-10-12 16:49 <cedk> udono: of course and there is no need | ||
| 2010-10-12 16:49 <bechamel> cedk: and because we test combination, there is no need of creating records ? | ||
| 2010-10-12 16:50 <cedk> bechamel: just somes | ||
| 2010-10-12 16:50 <udono> What does in mean 'creating of records'? | ||
| 2010-10-12 16:50 <cedk> bechamel: you make a scenario that does like a complete installation and configuration of Tryton and also some operations | ||
| 2010-10-12 16:50 <bechamel> this conversation is pointless as long as we don't know what those test will do | ||
| 2010-10-12 16:51 <cedk> bechamel: scenario is clear | ||
| 2010-10-12 16:51 <bechamel> cedk: example ? | ||
| 2010-10-12 16:52 <cedk> bechamel: you make a scenario that does like a complete installation and configuration of Tryton and also some operations | ||
| 2010-10-12 16:52 <cedk> bechamel: what do you do when you test a new module ? | ||
| 2010-10-12 16:53 <bechamel> cedk: I create a lot of records ... | ||
| 2010-10-12 16:53 <udono> cedk: For different scenarios we need different test suites/databases | ||
| 2010-10-12 16:53 <bechamel> and I test one or two result (stock level, invoice amount, etc) | ||
| 2010-10-12 16:55 <udono> E.g. I need to have one scenario creates 100000 Invoices and 100000 Payments in account_statement to test later the client performance by hand... | ||
| 2010-10-12 16:57 <udono> Other scenarios I need to test are given in: http://spreadsheets.google.com/ccc?key=tU28D4LEDJMkWmgMWfmbgXg | ||
| 2010-10-12 16:58 <udono> Another 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.org | ||
| 2010-10-12 17:01 <cedk> udono: a scenario must create a database, install module, configure and make some operations | ||
| 2010-10-12 17:02 <udono> cedk: yes, that's what I say. Each scenario needs own database/module configuration. | ||
| 2010-10-12 17:04 <bechamel> cedk: do you plan to repeat all those steps in each docstrings ? | ||
| 2010-10-12 17:04 <cedk> of course all those scenarii are not completly useful if there is no unittest | ||
| 2010-10-12 17:05 <udono> cedk: it is usefull because it tells me, that the tested functionality will work. | ||
| 2010-10-12 17:05 <udono> cedk: but you are right, on modul level there are a lot of todos in question of testing | ||
| 2010-10-12 17:07 <cedk> bechamel: there will not be a lot repeated | ||
| 2010-10-12 17:12 <udono> cedk: Tarec Ziade suggests in Expert Python Programming: http://paste.pocoo.org/show/274522/ | ||
| 2010-10-12 17:17 <cedk> udono: like I do :-) | ||
| 2010-10-12 17:18 <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 .. | ||
| 2010-10-12 17:20 <bechamel> cedk: btw, you told that testing taxes should be done with unittesting, so imo we should spend time on unit test before running to use proteus | ||
| 2010-10-12 17:21 <cedk> bechamel: it is what I said since 2 years | ||
| 2010-10-12 17:21 <udono> :-) | ||
| 2010-10-12 17:21 <cedk> bechamel: this doesn't prevent udono to write scenarii | ||
| 2010-10-12 17:21 <bechamel> so we spend the afternoon talking about stuff that are not really needed now | ||
| 2010-10-12 17:22 <cedk> with unittest we don't test a lot module interaction like with scenarii | ||
| 2010-10-12 17:22 <cedk> bechamel: no, because udono want to write scenarii for testing Tryton for the coming release | ||
| 2010-10-12 17:22 <cedk> like that his work will be not lost for the next release | ||
| 2010-10-12 17:23 <udono> cedk: you got it. I just don't like to test stuff like http://spreadsheets.google.com/ccc?key=tU28D4LEDJMkWmgMWfmbgXg in each release. It is too boring in the long run. | ||
| 2010-10-12 17:24 <bechamel> cedk: so it's up to him to choose the tool to write their tests :D | ||
| 2010-10-12 17:24 <pheller> what an enjoyable conversation to read :-) | ||
| 2010-10-12 17:25 <yangoon> cedk: where (in which fiels) would those doctests reside? | ||
| 2010-10-12 17:25 <yangoon> s/fiels/files/ | ||
| 2010-10-12 17:26 <bechamel> pheller: did you bring your pop-corn ? ;) | ||
| 2010-10-12 17:28 <udono> pheller: :-D | ||
| 2010-10-12 17:28 <Timitos> pheller: do not put more fuel to the fire ;-) | ||
| 2010-10-12 17:28 <cedk> yangoon: I guess in one Rest file | ||
| 2010-10-12 17:28 -!- evernichon(~evernicho@i01m-62-35-143-35.d4.club-internet.fr) has left #tryton | ||
| 2010-10-12 17:29 <cedk> bechamel: of course, udono can use the tools he wants but he was asking our opinions | ||
| 2010-10-12 17:35 <pheller> I'm curious, why not use cucumber or something else for scenario testing? | ||
| 2010-10-12 17:35 <cedk> pheller: it doesn't work :-) | ||
| 2010-10-12 17:35 <pheller> how about one of the python equivalents -- freshen or lettuce ? | ||
| 2010-10-12 17:35 <cedk> pheller: I mean the concept doesn't work | ||
| 2010-10-12 17:36 <pheller> ah, ok | ||
| 2010-10-12 17:36 <cedk> pheller: because the scenario should be written by end-users but generally they can not write good scenario | ||
| 2010-10-12 17:37 <cedk> bechamel: did you find the post about cucumber? | ||
| 2010-10-12 17:37 <pheller> ... and you think that they will be better able to write the test in python within a docstring? | ||
| 2010-10-12 17:38 <bechamel> cedk: http://afewgoodlines.com/post/1077316188/integration-testing-retrospective-part-i | ||
| 2010-10-12 17:41 <bechamel> IMO nothing beats python itself (neither doctest nor cumcumber) | ||
| 2010-10-12 17:41 <pheller> cedk: 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) | ||
| 2010-10-12 17:42 <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.... | ||
| 2010-10-12 17:45 <cedk> pheller: doctest is not simplify | ||
| 2010-10-12 17:45 <cedk> pheller: it is one of many testing framework | ||
| 2010-10-12 17:46 <cedk> pheller: I find it suite well the requirement of scenario | ||
| 2010-10-12 17:46 <pheller> cedk: 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. | ||
| 2010-10-12 17:46 <pheller> cedk: but, perhaps the best test of this --- why not write some examples in this manner and share them on the list? | ||
| 2010-10-12 18:53 -!- enlightx(~enlightx@dynamic-adsl-94-34-197-35.clienti.tiscali.it) has joined #tryton | ||
| 2010-10-12 18:55 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton | ||
| 2010-10-12 18:57 -!- drupin(~drupin@unaffiliated/drupin) has joined #tryton | ||
| 2010-10-12 19:19 -!- chrue(~chrue@dialin-65225.ewetel.net) has joined #tryton | ||
| 2010-10-12 19:20 -!- plantian(~ian@c-69-181-194-95.hsd1.ca.comcast.net) has joined #tryton | ||
| 2010-10-12 19:44 -!- paepke(~paepke@p4FEB0757.dip0.t-ipconnect.de) has left #tryton | ||
| 2010-10-12 20:37 <yangoon> cedk: could you please have a short look on http://codereview.appspot.com/2400042 | ||
| 2010-10-12 20:37 <yangoon> sorting of translation seems to be way lost | ||
| 2010-10-12 20:38 <yangoon> should I push nevertheless? | ||
| 2010-10-12 21:50 <cedk> yangoon: that is very strange | ||
| 2010-10-12 21:50 <cedk> yangoon: wait I will check | ||
| 2010-10-12 21:51 <yangoon> cedk: remembers me http://hg.tryton.org/trytond/rev/4e163c0d3e5a | ||
| 2010-10-12 21:52 <cedk> yangoon: should not be linked | ||
| 2010-10-12 21:56 -!- eLBati(~elbati@94.162.90.116) has joined #tryton | ||
| 2010-10-12 21:56 <yangoon> cedk: btw we had no bugfix release for account 1.6 since 4 months, for trytond 1.6 since 2 months | ||
| 2010-10-12 21:56 <yangoon> any plans for this? | ||
| 2010-10-12 21:57 <cedk> yangoon: I will do with 1.8 | ||
| 2010-10-12 21:57 <yangoon> cedk: great | ||
| 2010-10-12 22:02 <yangoon> cedk: btw, last btw btw hopefully;): http://hg.tryton.org/ shows paths like 1.6/neso/trytond | ||
| 2010-10-12 22:04 <cedk> yangoon: don't understand | ||
| 2010-10-12 22:05 <yangoon> 1.6/neso/trytond is a virtual repos and basically a duplicate of 1.6/trytond | ||
| 2010-10-12 22:06 <yangoon> important for hgnested, but not for webinterface | ||
| 2010-10-12 22:11 <cedk> yangoon: fixed | ||
| 2010-10-12 22:21 <cedk> yangoon: with which database backend are you translating? | ||
| 2010-10-12 22:21 <yangoon> cedk: this was with neso | ||
| 2010-10-12 22:21 <cedk> yangoon: so SQLite | ||
| 2010-10-12 22:21 <yangoon> yes | ||
| 2010-10-12 22:21 <cedk> yangoon: I think the sort is different than with PostgreSQL | ||
| 2010-10-12 22:22 <yangoon> urgghs | ||
| 2010-10-12 22:23 <cedk> yangoon: I think we could improve it by sorting in Python | ||
| 2010-10-12 22:26 -!- jcnorman(~jim@adsl-179-134-28.gsp.bellsouth.net) has joined #tryton | ||
| 2010-10-12 22:27 <jcnorman> I'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? | ||
| 2010-10-12 22:30 <cedk> jcnorman: are you on the same host? | ||
| 2010-10-12 22:31 <lem0na> jcnorman: i recieved the same error when can not connect to the database | ||
| 2010-10-12 22:32 <jcnorman> yes, i am | ||
| 2010-10-12 22:33 <yangoon> cedk: I must admit that sorting of sqlite seems more adequate in this case | ||
| 2010-10-12 22:33 <jcnorman> I'm starting trytond as user jim - checking to see if that's a valid postgresql user | ||
| 2010-10-12 22:33 <yangoon> comparing line 235 and 248 on http://codereview.appspot.com/2400042/diff/1/trytond/ir/de_DE.csv | ||
| 2010-10-12 22:34 <yangoon> seems to me not correctly sorted | ||
| 2010-10-12 22:34 <yangoon> on the left hand | ||
| 2010-10-12 22:35 <cedk> yangoon: the sort was done on type, name, src, res_id | ||
| 2010-10-12 22:36 <yangoon> 235 field,"ir.rule,field 236 field,"ir.rule.group 248 field,"ir.rule,operand | ||
| 2010-10-12 22:37 <yangoon> cedk: it doesn't handle point or comma | ||
| 2010-10-12 22:37 <jcnorman> Still no joy with seeing server - any suggestions? | ||
| 2010-10-12 22:38 <cedk> jcnorman: how is the login window? | ||
| 2010-10-12 22:38 <jcnorman> for database, shows Could not connect to server! | ||
| 2010-10-12 22:39 <cedk> jcnorman: which server name are you using? | ||
| 2010-10-12 22:40 <jcnorman> I've tried both localhost:8070 and 127.0.0.1:8070 | ||
| 2010-10-12 22:41 <yangoon> jcnorman: could you try with 0.0.0.0 for interface in trytond.conf | ||
| 2010-10-12 22:41 <jcnorman> Will do - I currently just have interface= | ||
| 2010-10-12 22:43 <jcnorman> still no joy | ||
| 2010-10-12 22:43 <lem0na> jcnorman: check permissions in pg_hba.conf | ||
| 2010-10-12 22:44 <yangoon> jcnorman: please paste the output of trytond -v | ||
| 2010-10-12 22:44 <jcnorman> OK - but ti's been working with openerp for a long time | ||
| 2010-10-12 22:44 <lem0na> jcnorman: can you connect with this user from psql ? | ||
| 2010-10-12 22:45 <jcnorman> will try | ||
| 2010-10-12 22:45 -!- plantian(~ian@c-69-181-194-95.hsd1.ca.comcast.net) has joined #tryton | ||
| 2010-10-12 22:46 <jcnorman> I can connect with psql | ||
| 2010-10-12 22:47 <jcnorman> when 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? | ||
| 2010-10-12 22:50 <cedk> jcnorman: yes | ||
| 2010-10-12 22:50 <jcnorman> which pastebin is in use? | ||
| 2010-10-12 22:51 <lem0na> jcnorman: i think that trytond is the default db user if nothing else specified in config file | ||
| 2010-10-12 22:51 <cedk> jcnorman: the one you prefer :-) | ||
| 2010-10-12 22:51 <cedk> lem0na: no it use the unix user that is running trytond | ||
| 2010-10-12 22:52 <jcnorman> http://pastebin.org/157484 | ||
| 2010-10-12 22:54 <cedk> yangoon: http://codereview.appspot.com/2450043 | ||
| 2010-10-12 22:54 <jcnorman> the conf file is http://pastebin.org/157602 | ||
| 2010-10-12 22:55 <yangoon> cedk: thx, will try | ||
| 2010-10-12 22:56 <cedk> jcnorman: and the server log? | ||
| 2010-10-12 22:57 <jcnorman> OK - just a moment | ||
| 2010-10-12 22:57 <yangoon> cedk: already on http://pastebin.org/157484 | ||
| 2010-10-12 22:58 <jcnorman> server log is: http://pastebin.org/157709 | ||
| 2010-10-12 22:59 <yangoon> jcnorman: if this is the most recent log, the server seems tobe connected to the databse | ||
| 2010-10-12 23:00 <jcnorman> Right, but the client is not seeing the server | ||
| 2010-10-12 23:00 <jcnorman> om 8070 | ||
| 2010-10-12 23:00 <jcnorman> on | ||
| 2010-10-12 23:02 <udono> jcnorman: hi, it seems the database connection. | ||
| 2010-10-12 23:03 <cedk> jcnorman: it seems that PostgreSQL requires a password for connection | ||
| 2010-10-12 23:03 <jcnorman> OK, whgere is that supplied? | ||
| 2010-10-12 23:03 <jcnorman> where | ||
| 2010-10-12 23:03 <lem0na> [Tue Oct 12 16:36:48 2010] INFO:database:connect to "fairmont" | ||
| 2010-10-12 23:03 <udono> jcnorman: the user which runs trytond must be able to connect to the database with the given passwordin line 35 of http://pastebin.org/157602 | ||
| 2010-10-12 23:03 <lem0na> i think you have to set trusted conenction | ||
| 2010-10-12 23:04 <lem0na> at least for this database | ||
| 2010-10-12 23:04 <lem0na> otherwise supply password | ||
| 2010-10-12 23:05 <udono> lem0na: jcnorman ... not to forget to use a more secure database connection later in production environment ... | ||
| 2010-10-12 23:08 -!- jcnorman(~jim@adsl-179-134-28.gsp.bellsouth.net) has joined #tryton | ||
| 2010-10-12 23:09 <jcnorman> Sorry - had to reboot - clicked on a link provided in irc and it started opening windows like crazy - couldn't stop it | ||
| 2010-10-12 23:11 <jcnorman> I've also tries logging in as user tryton with no joy. | ||
| 2010-10-12 23:13 <lem0na> jcnorman: do you start trytond with command parammeters? | ||
| 2010-10-12 23:14 <jcnorman> No | ||
| 2010-10-12 23:14 <jcnorman> sorry - that's configuring db user as tryton | ||
| 2010-10-12 23:18 <lem0na> interesting - i see command param for db_user but not for db_pass | ||
| 2010-10-12 23:19 <lem0na> jcnorman: can you add in pg_hba trusted connection for database fairmont - just for the test | ||
| 2010-10-12 23:19 <jcnorman> OK | ||
| 2010-10-12 23:24 <jcnorman> database fairmont doesn't yet exist | ||
| 2010-10-12 23:24 <lem0na> jcnorman: second option is to start trytond with --config=CONFIG where CONFIG is path to some config file with db_user and db_password | ||
| 2010-10-12 23:28 <jcnorman> I'm making progress - now have permission denied to create database - need to change grants on user tryton | ||
| 2010-10-12 23:29 <jcnorman> JOY!! JOY!! | ||
| 2010-10-12 23:30 <jcnorman> Thanks to all! | ||
| 2010-10-12 23:32 <jcnorman> Is there an easy way to get all modules? | ||
| 2010-10-12 23:33 <yangoon> jcnorman: http://code.google.com/p/tryton/wiki/InstallationMercurial | ||
| 2010-10-12 23:33 <yangoon> look for hgnested | ||
| 2010-10-12 23:33 <jcnorman> OK - thanks | ||
| 2010-10-12 23:33 <yangoon> ACTION afk | ||
| 2010-10-12 23:41 -!- lem0na(~lem0na@84.40.71.19) has joined #tryton | ||
| 2010-10-12 23:46 <jcnorman> Sorry, but I've gotten hgnested (both 0.1 and 0.2) setup.py install fails with (see http://pastebin.org/159093) | ||
| 2010-10-12 23:47 <jcnorman> I had hg version 1.4 - supported for Ubuntu 10.04. removed that, and still have the problem | ||
| 2010-10-12 23:48 <jcnorman> It seems to be failing with install of hg 1.6.4 | ||
| 2010-10-12 23:49 <cedk> jcnorman: you must update mercurial >= 1.5.0 | ||
| 2010-10-12 23:49 <jcnorman> Ok - I'll try the hg site | ||
| 2010-10-12 23:50 <cedk> jcnorman: otherwise you miss Python headers to compile mercurial |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!