2011/2/17 Grégory Starck <g.starck@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