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 <[email protected]>: > 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_2014 > [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 _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
