2011/2/17 Grégory Starck <g.sta...@gmail.com>
> [...]
>
>
> ok let's continue because it's now becoming (for me at least :p) nearly
> clear like crystal :
>
> so seeing/understanding that we have to "hack" like this the tests
> methods/code then shouldn't we change that, asap, in order to not have to
> hack like that/it's now :-?
>
> now that all the shinken daemons are classes that we can instanciate from
> shinken/daemons/* I think it should be easy(ier).
> Now we can really create any shinken daemon with any config file and this
> on the fly.. (somehow like in the test_bad_start) and then still control the
> daemon exactly as required/necessary by the test case (more or less easily
> depending on if the different daemon methods are correctly separated). The
> only problem is that I don't know very well (..) all the test cases/files
> currently used and I guess it'd be quite a good job to switch all them.. but
> I do think it'd be a good thing.
>
> wdyt ?
>
> but now so I understand that I've passed some too much hours on this
> false-negative test result , damn, you can laugh but I now have a clearer
> view at least (in fact clearer up to a certain point) :p
>
> greg.
>
> Hi,
Yes, the next level of testing will be with daemon class, that we didn't do
before becuase of the missing .py and so cannot load them. Now we can.
first, we can just solve the current case with just the deepcopy hack on
test_livestatus update_broks functions, but we should update the tests so
when we ask for a scheduler object, it got the conf from a real call, not
just by passing him direct arbiter object because it's not like that in the
real case.
So what we need to change after is the shinken_test.py file, and the setUp
function.
I'm stuck from keyboards for some days, but then I can help you on that if
you want after i finish the first version of the discovery script ;)
Jean
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
