[Cubicweb] Simple forms unit-testing

Julien Jehannet julien.jehannet at logilab.fr
Fri Nov 26 11:47:24 CET 2010


> * Adrien Di Mascio <adrien.dimascio at logilab.fr> [26-nov.-2010 09:35]:
> Hi,
> 
> In one of my projects, I've implemented a somewhat simple API to test
> the form rendering and submission. Let me tell immediately that this
> is **pure python / off-browser** testing and therefore means that
> this won't test any javascript / css / user interaction.
> 
> Using a lot of of forms in my application, my goal here was to be
> able to test automatically :
> 
> - visible fields (i.e. 'hidden', 'visible' fields in uicfg)
> - fields order
I hope we could have a more generic method for that (assertUicfg<something>()) ?

Another complementary add could be to enforce uicfg to be read-only once
defined in the application cube (kinda configuration over programming..).

> The underlying mechanism is fairly simple :
> (...)
> - this object holds also the lxml tree corresponding to the actual HTML
Very nice idea. Sure that will help xml validation as well.

> - `get_value` and `set_value` methods use the lxml tree to get / set
>   input values
IMO, we should use the dictionary syntax by keeping logic under the
hood.

> - form submission consists in three steps :
>   1. using lxml's form_values() method to build a dict-like object
>      based on actual input values
>   2. building a CubicWeb's request object around that dict-like object
>   3. using ctrl_publish() to process the request and go through the
>      edit controller chain
I'm +1 to commit your assert methods (in devtools/httptest.py).
Note that some helper methods already exist (web_*) for web testing.


In a general way, I'm not in favour to add a new API above the actual
one (except assertion methods of course).
At the contrary, we have to improve the framework to reflect the
testing needs and to facilitate TDD by default.

Here what I should considered as a cool developpement workflow in a
large part:

1. write specification in unit test (uicfg, web behaviour, ...)
2. use right assert methods on it (we have to create them)
3. when test pass, move the logic part into the real code and in case of
appobject, just retrieve/select it in front of the test.

But we must keep in mind that common API is mandatory to be able to
process 3 easily.
-- 
Julien JEHANNET                                          LOGILAB, Paris (France)
http://www.cubicweb.org                 CubicWeb, le cadriciel du web sémantique
http://www.logilab.org             Dépôt des logiciels libres conçus par Logilab
http://www.logilab.fr       Informatique scientifique & Gestion de connaissances



More information about the Cubicweb mailing list