Cut down long-running unit tests about bctpy HOT 3 CLOSED

No, I don't think so.

With reference to the one unit test of test_link_communities, the test case is as follows:

def test_link_communities():
    x = load_sample(thres=0.4)
    seed = 949389104
    M = bct.link_communities(x)
    assert np.max(M) == 1

This four line test case takes over an hour to run.

The reason is, the algorithm is simply very slow. I didn't write the algorithm, the people who designed it wrote it to be very slow. The python implementation is even slower. I haven't explored why the python implementation is very slow, but even the matlab implementation would take more than ten minutes to run I suspect.

I don't know how to fix it. At some point I may return to this function to try to see if I can optimize the algorithm to at least achieve closer to the matlab performance, but that would take a lot of effort and I don't have time to do that right now.

I would actually favor commenting out the unit test for now if it is a serious problem that the test runs too long, because I think link_communities takes too long to run for anyone to want to use it anyway when they could get mostly acceptable performance from functions like modularity_und.

from bctpy.

Agreed on that, I'd be happy to disable the test and maybe stick a warnings.warn("Don't use this algorithm") in the method itself. I was more wondering if the sample data could be simplified so that the algorithm was doing the bare minimum to prove function, but glancing at the algorithm I guess it needs quite a complex data set to return much at all.

from bctpy.

Just going through the tests at the moment so I'll note down the ones which might be problematic:

nbs_tests.py: quite slow
modularity_derived_metrics_test.py: some runtime warnings

from bctpy.