Make unit tests fail with a descriptive error message if local ipfs daemon node is not running

[ntninja]

Fixes #53

[whereswaldon]

So I follow that this is a decorator, but not how it works when you're decorating the test classes. Could you explain the interaction to me? How does this work since skipIfOffline doesn't accept parameters?

[ntninja]

Decorators (in Python) are actually just pretty syntax around the magic __call__(*args, **kwargs) method.

Therefor:

@skipIfOffline()
def test_somehting():
    …

is the same as:

def test_something():
   …
test_something = skipIfOffline()(test_something)

were the skipIfOffline() part invokes the skipIfOffline function and (temporarily) stores the result. The result returned by skipIfOffline is in also a callable, that then gets invoked with the actual method as parameter. This second callable will then return another callable, that is later invoked as actual unit test by the test harness.

Definitely ask for clarification if this is hard to grasp for you (layers, layers, LAYERS). 😉

[whereswaldon]

I may not understand how it works, but it does work. I've tested it out on my machine. Thanks for putting this together!

[ntninja]

Thanks for your feedback!

[joshisa]

@Alexander255 Out of curiosity, is the def is_available exposed as a part of the client api set. If not, any thoughts on value in doing so? I stumbled across an issue in another consuming project oduwsdl/ipwb that showed interest in leveraging a daemon check api if it existed in py-ipfs-api .

[ntninja]

@joshisa Thanks for pointing this out, I didn't think about the the broader issue at hand to be honest. The currently implementation is just a quick fix for the unit tests through, that just checks whether there is something running on the default IPFS host and port.
To formalize this we probably should add a new function (maybe ipfsapi.connect()?) that creates a new client instance and tries to call some API call (such as version()). On success you'd get the ipfsapi.Client-instance, on failure you'd get an exception. Do you think that'd be a proper solution?

[whereswaldon]

That'd be alright I think. We could even check the version given against what we support and throw an error if it's unsupported.

On Aug 25, 2016, at 10:59 AM, Alexander Schlarb [email protected] wrote:

@joshisa Thanks for pointing this out, I didn't think about the the broader issue at hand to be honest. The currently implementation is just a quick fix for the unit tests through, that just checks whether there is something running on the default IPFS host and port.
To formalize this we probably should add a new function (maybe ipfsapi.connect()?) that creates a new client instance and tries to call some API call (such as version()). On success you'd get the ipfsapi.Client-instance, on failure you'd get an exception. Do you think that'd be a proper solution?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.