[Freeipa-devel] QUnit and unit testing

[Adam Young]

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.

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.  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.