Changes between Version 7 and Version 8 of Obsolete/Development/Code/TestingComponents

Timestamp:

Apr 24, 2012, 11:29:12 PM (14 years ago)

Author:

munoz

Comment:

--

Obsolete/Development/Code/TestingComponents

@@ -117 +117 @@
 }}}
 
-=== Testing the `Configure` method ===
+=== Testing with real profiles (the `Configure` method) ===
 
-This method should have almost no logic. But it still deserves some testing. It must receive a valid `EDG::CCM::Configuration` object from a profile. And handling this is done by `Test::Quattor`. This is how we do it:
+Sometimes it's more convenient to have a mockup profile, and get that configuration. Here comes my advice:
 
-1. We have a set of test profiles. They are minimalistic, and have no dependencies on any "standard" templates. Just assign a few values to fill in your component structure. For instance:
+1. Have a set of test profiles. They should be tiny and have no dependencies on any "standard" templates. Just assign a few values to fill in your component structure. For instance:
 {{{
 #!sh
@@ -130 +130 @@
 "b" = 2;
 }}}
-1. This profile must be compiled, and a cache must be created for it. The `Test::Quattor` comes in hand here: If you pass any arguments to it, it will compile them and prepare the correct cache:
+1. These profiles must be compiled and a cache created for it. `Test::Quattor` comes in hand here: If you pass any arguments to it, it will compile them and prepare the correct cache:
 {{{
 #!perl
@@ -145 +145 @@
 $comp->Configure($config);
 }}}
+1. Or, if your tests can benefit from it, extract portions of it with `getTree()`:
+{{{
+#!perl
+my $t = $config->getElement("/software/components/foo")->getTree();
+$comp->a_lesser_method($t->{a_subtree});
+}}}
 
 And test whatever you need to test. Simple, right?
+
+Always remember that the `Configure` method should be terribly simple, with almost no logic. The bulk of your tests will focus in the methods of your component that do the real work.
 
 == Running the tests ==