Skip to content
This repository has been archived by the owner on Mar 10, 2020. It is now read-only.

Make solid tests for node-ipfs-api #81

Merged
merged 61 commits into from
Oct 28, 2015
Merged

Make solid tests for node-ipfs-api #81

merged 61 commits into from
Oct 28, 2015

Conversation

daviddias
Copy link
Contributor

This endeavour was started and pushed forward by @dignifiedquire and @victorbjelkholm (<3 ref: #78 #77), but we welcome anyone who wants to contribute.

Goal: Have a complete test suit for node-ipfs-api that test both in Node.js and in the Browser.
Stretch goal: Have code coverage checking

This PR will be focused on making tests for IPFS version 0.3.7 (version 0.3.8 will require an update on the request-api.js parser)

Historically, we have had problems because tests are using the global network to perform the DHT queries, this makes testing slow and somewhat unreliable. Tests should their own IPFS cluster, for testing against the global network, we must have integration tests, but that can be the next step.

API

  • before tests run
  • .send
    • node.js
    • browser
  • .add
    • .add a file
      • node.js
      • browser
    • .add a buffer
      • node.js
      • browser
    • .add a path
      • node.js
      • browser
    • .add a folder (nested)
      • node.js
      • browser
  • .cat
    • node.js
    • browser
  • .ls
    • node.js
    • browser
  • .config
    • .config.get
      • node.js
      • browser
    • .config.set
      • node.js
      • browser
    • .config.show
      • node.js
      • browser
    • .config.replace
      • node.js
      • browser
  • .update (Currently disabled, wait for version 0.4.0 release)
  • .version
    • node.js
    • browser
  • .commands
    • node.js
    • browser
  • .mount (Requires FUSE, not practical for testing in node-ipfs-api)
  • .diag
    • .diag.net
      • node.js
      • browser
  • .block
    • .block.get
      • node.js
      • browser
    • .block.put
      • node.js
      • browser
  • .object
    • .object.get
      • node.js
      • browser
    • .object.put
      • node.js
      • browser
    • .object.data
      • node.js
      • browser
    • .object.stat
      • node.js
      • browser
    • .object.links
      • node.js
      • browser
  • .swarm
    • .swarm.peers
      • node.js
      • browser
    • .swarm.connect
      • node.js
      • browser
  • .ping
    • node.js
    • browser
  • .id
    • node.js
    • browser
  • .pin
    • .pin.add
      • node.js
      • browser
    • .pin.remove
      • node.js
      • browser
    • .pin.list
      • node.js
      • browser
  • .gateway this doesn't exist anymore on the http api
    • .gateway.enable
    • .gateway.disable
  • log
    • log.tail (needs 0.3.9 ndjson stuff)
  • .name
    • .name.publish
      • node.js
      • browser
    • .name.resolve
      • node.js
      • browser
  • .Buffer (do we still need to expose Buffer? Node.js now uses TypedArrays, so it shouldn't be necessary)
    • node.js
    • browser
  • .refs
    • .refs.local
      • node.js
      • browser
  • .dht
    • .dht.findprovs
      • node.js
      • browser
    • .dht.get
      • node.js
      • browser
    • .dht.put
      • node.js
      • browser

@daviddias
Copy link
Contributor Author

@whyrusleeping ls and refs are weird, before they would fail half of the time and we thought it would be because of having to query a big chunk of the network, but now, I've made it with 3 nodes only (disabled Bootstrap and mDNS and connected them manually) and they still fail. Thoughts?

if (isNode) {
startIndependentNode(ipfsNodes, apiClients, 'a', finish)
startIndependentNode(ipfsNodes, apiClients, 'b', finish)
startIndependentNode(ipfsNodes, apiClients, 'c', finish)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dignifiedquire how can we achieve the spawning of several nodes in Karma, but in a helper script, since this can't be executed from the browser?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest we write a script to start karma instead of using the cli, similar to this and then we can wrap the karma start and stop into start and stop of the nodes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, then starting the nodes by gulp scripts as well? What is the best way to pass the disposable Node addrs to the Karma test?

Should the Node.js tests also use Gulp to spawn the disposable Node.js?

Trying to figure out what is more common/clean for these type of situations. Thank you for the guidance :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My thinking is along these lines:

  1. Gulp starts x disposable nodes
  2. Trigger node test run (only tests relying on nodes running)
  3. Trigger browser test run
  4. Gulp stops all nodes
  5. Trigger node tests that involve manual start and stop of nodes (like https://github.com/ipfs/node-ipfs-api/blob/master/test/test.js#L290-L301)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice! so, would the best way to pass the apiAddrs of the nodes be to pass them through a tmp conf object such as configFile: __dirname + '/karma.conf.js', ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For dynamic values in the karma.conf you can just pass those through the api call, but to ensure the tests in node as well in the browser have the right apiAddrs I suggest writing them to a file like test/fixtures/addrs.txt and then reading this file from the tests.

@daviddias
Copy link
Contributor Author

pushed last batch of tests for this branch. now it is all about getting it run in the browser :)

@dignifiedquire
Copy link
Contributor

@diasdavid pushed fixes for pretty much most of the browser stuff and cleaned up gulp a bit. A couple of things left to do

@daviddias
Copy link
Contributor Author

sweet! thank you @dignifiedquire :) Just ran it in Sauce Labs and got some passing tests too:) However, running in debug bug still yields the same error to me

» DEBUG=true gulp test:browser                                   ◉ ◼◼◼◼◼◼◼◼◼◼
module.js:339
    throw err;
    ^

Error: Cannot find module 'vinyl'

On:

Add sauce labs credentials to circleci
@lgierth, would you be the best person to handle this part? So that we can keep using it for any other browser module?

@daviddias
Copy link
Contributor Author

DEBUG mode is working fine for me now (apparently I had a old version of gulp installed)

One thing I noticed is that karma fires all the browser tests on top of the same daemons, which might result well because adding to IPFS is idempotent, but kind of unfair, since if one of the add operations fails in one of the browsers, verifying that it is there will still pass. Thoughts?

@dignifiedquire
Copy link
Contributor

Make the content of the testfile be equal to the ua string, problem solved :P

@daviddias
Copy link
Contributor Author

ua string?

@dignifiedquire
Copy link
Contributor

ua string?

User agent string:

navigator.userAgent
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36"

@daviddias
Copy link
Contributor Author

but with that, we can't know the hash beforehand as new browser versions will come up. The test is about adding something we can get the hash manually via ipfs add.

I'm thinking on pushing the remaining tasks as 'next', so that we can upgrade node-ipfs-api to 0.3.9. What is your opinion?

Remaining tasks:

@dignifiedquire
Copy link
Contributor

Well you don't know the hash in advance but you could instead of checking the hash against a fixed version use cat to get the content after the add and compare the content.

I'm fine with pushing the remaining tasks to next and creating separate issues.

@daviddias
Copy link
Contributor Author

🚢

daviddias added a commit that referenced this pull request Oct 28, 2015
Make solid tests for node-ipfs-api
@daviddias daviddias merged commit 645000f into master Oct 28, 2015
@dignifiedquire
Copy link
Contributor

sweet ⭐️⭐️

@victorb
Copy link
Contributor

victorb commented Oct 28, 2015

Finally! Great job @dignifiedquire @diasdavid 👍👍🏻👍🏻👍🏻👍🏻👍🏻

@daviddias
Copy link
Contributor Author

Thank you both for kicking things off and helping shipping it :D

@jbenet
Copy link
Contributor

jbenet commented Nov 2, 2015

@daviddias daviddias deleted the solid-tests branch November 2, 2015 04:17
@gavinmcdermott
Copy link
Contributor

@diasdavid, I started looking into the codebase tonight and added a couple of tests. Wondering if you would add me to the repo so I can open a PR for review? If so, thanks much!

@daviddias
Copy link
Contributor Author

@gavinmcdermott That is awesome! Could you make the PR from your fork?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants