Skip to content
This repository has been archived by the owner on Aug 1, 2023. It is now read-only.

test: add dht interop tests #36

Closed
wants to merge 5 commits into from
Closed

Conversation

vasco-santos
Copy link
Member

@vasco-santos vasco-santos commented Sep 17, 2018

@ghost ghost assigned vasco-santos Sep 17, 2018
@ghost ghost added the status/in-progress In progress label Sep 17, 2018
Copy link

@jhiesey jhiesey left a comment

Choose a reason for hiding this comment

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

Looks good, just a few small comments. Do these tests pass at the moment?

Is it deliberate that there aren't tests that go over multiple hops (other than through the bootstrap node) anymore?

I think the way it is is fine, but have you considered a templated version of this test that just lets you specify the types of node0 through node3 and then call a function to run the test? I'm not very familiar with mocha so I don't know if that's tricky or not.

test/kad-dht.js Outdated
}, callback)
}

const getNodeId = (node, callback) => {
Copy link

Choose a reason for hiding this comment

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

Maybe call this getBootstrapAddr?

Copy link
Member Author

Choose a reason for hiding this comment

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

Better naming yes, I will change it!

test/kad-dht.js Outdated Show resolved Hide resolved
@vasco-santos
Copy link
Member Author

Hey @jhiesey

Thanks for your help.

Looks good, just a few small comments. Do these tests pass at the moment?

The tests pass locally if you change the following here (node_modules):

start (callback) {
    this._running = true
    this.network.start((err) => {
      if (err) {
        return callback(err)
      }
      this.randomWalk.start(1, 100)

      callback()
    })
  }

Attention, this is not an appropriate change, as we should use the randomWalk defaults, but for that we have to change the way it is implemented with setInterval. I have started working on it yesterday, and hopefully today I will have a change to propose.

Is it deliberate that there aren't tests that go over multiple hops (other than through the bootstrap node) anymore?

I would like to create the tests with multiple hops as they were before. However, I don't know how to create a test in that format. The previous implementation of that format connected all the peers in a sequence. That way, the test was running successfully with the DHT disabled, so I believe that it was not a valid test. If you have any network suggestion to achieve that, I would like to add it!

I think the way it is is fine, but have you considered a templated version of this test that just lets you specify the types of node0 through node3 and then call a function to run the test? I'm not very familiar with mocha so I don't know if that's tricky or not.

I will have a refactor on this later, this is just a WIP for now, and before getting it ready for merging, I will try to reuse the most of the duplicated code.

@vasco-santos vasco-santos force-pushed the add-dht-interop-tests branch 5 times, most recently from 38730b9 to 18ae27b Compare October 29, 2018 12:16
@vasco-santos vasco-santos changed the title [WIP] chore: add dht interop tests chore: add dht interop tests Oct 29, 2018
@vasco-santos vasco-santos added the status/blocked Unable to be worked further until needs are met label Oct 29, 2018
@daviddias daviddias changed the title chore: add dht interop tests test: add dht interop tests Oct 29, 2018
@jacobheun
Copy link
Contributor

DHT interop tests look good. We need to get ci green before this is good. If there are flakey, unrelated tests we should get a PR to resolve those. Right now the job history for this PR has no successes https://ci.ipfs.team/blue/organizations/jenkins/IPFS%2Finterop/activity?branch=PR-36

@vasco-santos
Copy link
Member Author

@jacobheun in the last time that I ran the tests all were ok for the DHT tests, and the ones that failed were due timeouts:

https://ci.ipfs.team/blue/organizations/jenkins/IPFS%2Finterop/detail/PR-36/9/pipeline/361

This way, I wanted to have feedback about the PR before trying to have the all CI green.

@vasco-santos vasco-santos force-pushed the add-dht-interop-tests branch 3 times, most recently from 0a37a7e to 36285ce Compare November 11, 2018 14:05
test/browser.js Show resolved Hide resolved
test/kad-dht.js Outdated Show resolved Hide resolved
test/kad-dht.js Outdated Show resolved Hide resolved
test/kad-dht.js Outdated Show resolved Hide resolved
test/kad-dht.js Outdated Show resolved Hide resolved
test/kad-dht.js Outdated Show resolved Hide resolved
test/kad-dht.js Show resolved Hide resolved
test/kad-dht.js Show resolved Hide resolved
@vasco-santos vasco-santos force-pushed the add-dht-interop-tests branch 2 times, most recently from 1fe3d4c to 2b576c5 Compare January 10, 2019 11:06
@daviddias
Copy link
Member

@vasco-santos mind rebasing master onto this PR and test it with js-ipfs master?

@daviddias daviddias changed the title test: add dht interop tests [WIP] test: add dht interop tests Feb 13, 2019
@alanshaw
Copy link
Member

alanshaw commented Apr 4, 2019

@vasco-santos what's the status of this? Can we get CI green and merge?

@vasco-santos
Copy link
Member Author

Now we are able to also add the libp2p options through the daemon.spawn 🎉

I will work on getting this updated with green CI

@vasco-santos
Copy link
Member Author

@alanshaw this should be ready to go. What do you think?

@vasco-santos vasco-santos removed the status/blocked Unable to be worked further until needs are met label Aug 4, 2019
@daviddias
Copy link
Member

@vasco-santos mind rebasing master to confirm that CI is still green for clean merge?

@vasco-santos
Copy link
Member Author

ready to go @daviddias

@@ -3,7 +3,7 @@

// require('./exchange-files')
// require('./pubsub')
require('./kad-dht')
// require('./kad-dht')
Copy link
Member

@daviddias daviddias Sep 2, 2019

Choose a reason for hiding this comment

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

This means it is not being tested. Is that intended?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, more info: #36 (review)

I can have a look after to that issue with id(), but I think that it should not be a blocker for this. I can create an issue to track it, as I think it is better to have these tests in now, than have nothing

Copy link
Member Author

Choose a reason for hiding this comment

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


callback(null, res.addresses[0])
})
}
Copy link
Member

Choose a reason for hiding this comment

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

This function is a tad misleading. All it does is extract the first listing address of a node. Perhaps rename to getNodeAddr?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, agree! I will change that!

done()
})
})
})
Copy link
Member

Choose a reason for hiding this comment

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

It only tests the bootstrap with a JS Daemon, should be tested symmetrically (i.e. with go being the bootstrapper)

Copy link
Member Author

Choose a reason for hiding this comment

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

I am not sure if I understand your comment. But, I think I have those tests in the suite tests below

Copy link
Member

Choose a reason for hiding this comment

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

I see now below that the inverse happens

Copy link
Member

@daviddias daviddias left a comment

Choose a reason for hiding this comment

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

I don't see any tests for situations where it is expected to fail, for example: two disjoint networks exist, seeking in one side succeeds and in the other fails, then, when both connect, seeking in both side succeeds

before(function (done) {
this.timeout(70 * 1000)
const peersToSpawn = 3
const bootstrap = bootstrapAddr ? [bootstrapAddr] : []
Copy link
Member

Choose a reason for hiding this comment

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

In which case will bootstrapAddr not be available?

spawnJsDaemon(bootstrap, (err, node) => {
expect(err).to.not.exist()
nodes.push(node)
next(err, node)
Copy link
Member

Choose a reason for hiding this comment

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

Why pass err here if it won't exist? Also, why pass node if you don't use the results out of the times call?

}
cb(null, peers.length === peersToSpawn)
})
}
Copy link
Member

Choose a reason for hiding this comment

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

This function seems to only be testing if the first node is connected to all the other peers. It means that either:

  • The name testDhtReady is incorrect
  • It is creating a full mesh which will then defeat a bit of the purpose of testing the DHT

done()
})
})
})
Copy link
Member

Choose a reason for hiding this comment

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

I see now below that the inverse happens

it('should get from the network after being added', function (done) {
this.timeout(60 * 1000)

addFileAndCat(nodes[1], [nodes[2], nodes[3]], data, done)
})
})
})
Copy link
Member

Choose a reason for hiding this comment

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

@vasco-santos I believe the tests above would be better if the tests were described through which nodes play which role (who is the node providing the content, who is the node fetching the content, who is the node bootstrapping the network, who are the other nodes) and make it just a simple config rather than hard wiring things by hand in every test.

What do you think?

})
})
})

describe('a Go node in the land of JS', () => {})
describe('hybrid', () => {})
describe('kad-dht with connections per peer', () => {
Copy link
Member

Choose a reason for hiding this comment

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

What does it mean "with connections per peer"?

addFileAndCat(nodes[2], [nodes[3]], data, done)
})
})
})
Copy link
Member

Choose a reason for hiding this comment

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

Again, this batch of tests could be more clean if instead of c&p the tests, they were only written once and then called multiple times with the different node configurations

achingbrain added a commit that referenced this pull request Oct 1, 2021
Adds additional tests from #36 as well as some extras requested in
the PR comments.

Refs: ipfs/js-ipfs#3905
@achingbrain
Copy link
Member

Superseded by #376

@achingbrain achingbrain closed this Oct 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants