MikaLendingBot
MikaLendingBot copied to clipboard
BitBotFactory
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
RE: Implementing unit tests. Yes, yes, one thousand times yes.
RE: Experience. I've used nose and Jenkins a lot in the past to do this kind of thing. Though that should carry over to other setups. Normally what you'd do is have a post commit hook that runs the unit tests. Presumably travis is the best thing to use on github.
Though you should also be able to run those tests locally via nose (or something else, that's just what I've used).
In nose you just create a test folder, then put everything in there. Any function that starts with the name test will be run, you do your setup and whatnot in there, so we'd need a generic polo account to connect with, or a way to mock responses.
I've no idea about the Codacy stuff, though what more do you want to add that it's not already doing?
Happy to help out though.
@laxdog That's great! Could you make the initial setup (I haven't done this for python) ?
As a first test I would like to test the Analysis module which should be simple enough.
When you have time can you share some information on how the setup will work?
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.
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.
Module is changing and so will the tests. Keeping this open and assigning to me.
Actually I already implemented a unit test for the API change, I think this issue should be closed, however we should add unit tests to future PRs where possible.