[Freeipa-devel] QUnit and unit testing

[Endi Sukma Dewata]

----- "Adam Young" <ayoung at redhat.com> wrote:

> I've started playing around with QUnit.  I think it is the right too
> for Unit testing in q JQuery based application.
> 
> One thing that has become clear pretty quickly is that most of our
> code is dependant upon ipa_cmd.  We are going to need to have a more
> flexible scheme for specifying whether we want a success, an semantic failure,
> or an RPC failure from each call.  I think the sampledata scheme that we
> have thus far will get us started, but I think maybe it is time to
> start teasing apart concerns for the various objects.
> 
> I'd like to make ipa_cmd and object instead of just a flat function 
> call.  The API should be something like: Constructor  takes the 
> success,  error, and failure callbacks, object name, and method. The 
> execute method takes the params and args.

+1 on converting ipa_cmd into a class, but I have a sligtly different
suggestion on the class interface:

IPA class:
- IPA(path, type): Construct IPA object given a path to server's JSON-RPC or
                  static files.
- success(): Default success handler.
- error(): Default error handler.
- failure(): Default failure handler.
- execute(methodName, params, options, [success], [error], [failure]):
  Execute a method with optional handlers. The methodName should include
  the object name.

For the Web UI we could create a global IPA object that points to JSON-RPC
or sample data based on the current URL. The IPA object can be reused, each
entity only needs to invoke the execute() method and provides necessary
handlers.

For each test we could create IPA object that points to specific test data.

> The various Entities will have the logic for how to create their own
> IPA Commands.   Search, details, and the other UI pieces will take a
> Command object as one of the constructor params.   Thus, the first focus of
> the unit testing framework will be to test the  UI pieces.
> 
> One place where JavaScript is weak is in enforcing design by contract.
> We need to use JUnit to catch for us the places where the contract is
> or is no met. I'm not sure how we can catch things like
>      "The details object has changed its API from 'exec' to 'execute'
> 
> but we are still calling exec"
> and catch it in Unit tests.

We might be able to call alert() in the old interface. Once the test
is completed without any errors we could remove the old interface.

>  I suspect that what we will find is that
> much of the callback logic defined in the various structures will get
> extracted out to helper classes instead.
> 
> What I've found working in C, Java, and C++ is that a good Inversion
> of Control approach greatly improves reuse and maintainability of your 
> project.  I am still working out how to apply the concept to 
> Javascript.  As far as scopes go, I figure we pretty much have two:  
> application and hashchange.  Our eneity files are pretty much the 
> configuration for the system.  As such, we want to minimize the 
> behaviour defined in them.  A function should be defined in an entity
> file only if it truly is a one time deal.  Even then, they should be a
> s small as possible, really to pull together two aspects  from the rest
> of the system:  wiring things up.

--
Endi S. Dewata