Unit testing

We would like to implement unit testing for modules that is activated when run with something like the --runtests argument.

Implementing this would make it much easier to see when a change breaks something important.

We plan on integrating with Codacy’s coverage system. https://support.codacy.com/hc/en-us/articles/207312879-Generate-Coverage

[laxdog]

The more I look at this, the more I think there needs to be a major rewrite. It’s been written in a way that tries to re-implement classes with liberal use of globals. It would be much better if they were all proper python classes with init()

Also, we shouldn’t really be starting threads and processing during the init function. It means in testing for example, I can’t just initialise a class to call some methods without having it actually running and doing things I don’t want it to behind the scenes. It becomes especially problematic when I want to have multiples as they start messing with each others files.

Unfortunately it’s a bit of a chicken egg scenario as really we’d want tests to rewrite the modules, but I want to rewrite the modules to write the tests.

Given the position though, I think it’s best to get the tests done to start, then begin moving the modules and tests to a new structure. This means though I’m going have to add a new parameter to a lot of the functions so I can pass the variables we’re interested in to it (to avoid creating a new ‘instance’).

I’ll raise a PR for what I’ve got so far, but I need to redo a lot of it. The frameworks I’m using are nose and hypothesis, but I’ve found out recently that nose is pretty much dead and people have moved to py.test mostly.

[laxdog]

Haven’t forgotten about this, just haven’t had time yet. I’m on vacation soon too, so it’s going to be a few weeks.