-
Notifications
You must be signed in to change notification settings - Fork 300
Conversation
@whyrusleeping |
if (isNode) { | ||
startIndependentNode(ipfsNodes, apiClients, 'a', finish) | ||
startIndependentNode(ipfsNodes, apiClients, 'b', finish) | ||
startIndependentNode(ipfsNodes, apiClients, 'c', finish) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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:
- Gulp starts x disposable nodes
- Trigger node test run (only tests relying on nodes running)
- Trigger browser test run
- Gulp stops all nodes
- 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)
There was a problem hiding this comment.
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',
?
There was a problem hiding this comment.
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.
pushed last batch of tests for this branch. now it is all about getting it run in the browser :) |
@diasdavid pushed fixes for pretty much most of the browser stuff and cleaned up gulp a bit. A couple of things left to do
|
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
On:
|
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? |
Make the content of the testfile be equal to the ua string, problem solved :P |
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" |
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:
|
Well you don't know the hash in advance but you could instead of checking the hash against a fixed version use I'm fine with pushing the remaining tasks to next and creating separate issues. |
🚢 |
Make solid tests for node-ipfs-api
sweet ⭐️⭐️ |
Finally! Great job @dignifiedquire @diasdavid 👍👍🏻👍🏻👍🏻👍🏻👍🏻 |
Thank you both for kicking things off and helping shipping it :D |
@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! |
@gavinmcdermott That is awesome! Could you make the PR from your fork? |
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
.update(Currently disabled, wait for version 0.4.0 release).mount(Requires FUSE, not practical for testing in node-ipfs-api).gatewaythis doesn't exist anymore on the http api.gateway.enable.gateway.disable