On 09/13/2010 12:51 PM, Endi Sukma Dewata wrote:
----- "Adam Young"<[email protected]> 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.
execute has a lot of parameters. I think I would prefer a simple
execute(args, options,caller)
It could then be called
cmd.execute(args, options,this)
The constructor can take a spec like this
var cmd = command({entity: e, method:m, succes:s , error: e,
failure f});
and then we can check for the presence of each of the parameters.
The inline case would be
command({entity: e, method:m, succes:s , error: e, failure
f}).execute(args, options);
caller would be an object that respects the contract
{
on _error = function(){...}
on_success = function(){...}
on_failure= function(){...}
}
With each of these functions being optional. If set, they get called in
place of the Command members.
The prototype for command should have a default implementation for
error, success, and failure. New instance should be created using a
clone, with the default as the prototype.
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
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
