I asked Yohann and he answered me: He based his module on a module of the Django framework: Model Mommy: https://pypi.python.org/pypi/model_mommy. 2014-09-10 15:35 GMT+02:00 Jonathan Druart <jonathan.druart@biblibre.com>:
Hello developers,
Yesterday the TestBuilder case has been discussed during the meeting [1]
I will try to list the pros and cons points as objectively as I can: Pros: - the module meets a need: simplify the writing of tests
Cons: - it's another tool to learn - it should be covered by unit tests - it should be maintain - it hides the way how it works under the hood - it is not hard to create required rows in dependent tables
That was the objective part. Now, since I would like to see TestBuilder [2] integrated into master, I will try to provide arguments.
The need is to simplify the writing of tests, especially for the acquisition module. An easy goal could be to be data agnostic, random data could be generated as the beginning of all test files. So yes, it is another tool to learn, but the way we are writing tests for now is not elegant and maintain them will be a pain. The tool has been provided (by Yohann) with its own unit tests, no need to write them (hopefully!). The api is quite easy to learn (only 2 public methods: build and clear). I don't think this module will hide "how it works under the hood", the guys who will use them are going to add/write/rewrite a new routine and already know the DB structure. I would like to add that I don't think this module should be mandatory. A developer should be free not to use to it.
Some examples have already been provided, which will help developers who want to use it. I would add that it is not "hard" to manually generate dependencies, just a waste of time. And it adds useless complexity in the tests files. When you have to create a library, a bookseller, a basket and a biblio to create an order, sometime for 1 test, it does not encourage developers to write tests. I think the best example is bug 12604 [3]. It is the same if you want to issue an item to a patron, you will have to create a library, a patron category, a patron, a biblio and the item. Developers are lazy, they just want to tell "give me a patron and an item!".
I am sure this is certainly not the best implementation. It has been done by an intern in 2 weeks. He didn't know perl or Koha 1 month before. Yohann provided a very good work. Moreover he based his work on a python library doing the same thing (I don't remember the name :-/) Note that some other modules already exist [4], but they won't work out of the box like TestBuilder. Maybe for our next intern :)
Cheers, Jonathan
Ps: to keep in mind whose this module will be useful, you can run the following command: python gitinspector.py ~/src --since=2013-01-01 --file-types=t It will generate statistics for test files by author since 2013 (for busy guys, you can see the result here: http://paste.koha-community.org/199)
[1] http://wiki.koha-community.org/wiki/Development_IRC_meeting,_9_September_201... [2] Bug 12603 - TestBuilder - Module to simplify the writing of tests [3] Bug 12604: refactoring close_reopen_basket.t with TestBuilder [4] http://search.cpan.org/dist/DBIx-Class-Fixtures/lib/DBIx/Class/Fixtures.pm or Test::DBIx::Class:Factory