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

Added tests of PublicResolver. #84

Merged
merged 4 commits into from
Mar 28, 2017

Conversation

xavierlepretre
Copy link
Contributor

No description provided.

Copy link
Member

@Arachnid Arachnid left a comment

Choose a reason for hiding this comment

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

These largely look great - thanks for writing them! Just a few comments.

})
.then(contract => {
resolver = Promise.promisifyAll(contract);
ens.setSubnodeOwnerAsync(0, web3.sha3('eth'), accounts[0], {from: accounts[0]});
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't there be a return statement here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Damn!


describe('constructor', function() {

it('should not allow a 0 address for ens');
Copy link
Member

Choose a reason for hiding this comment

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

??

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Shouldn't there be a test in the constructor making sure that it was not passed the address 0 for ens?

Copy link
Member

Choose a reason for hiding this comment

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

I don't think that's any different to passing any other invalid address for ENS; if you do that, the contract simply won't function.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it would not function, but since you cannot change the ens address in the resolver instance, it is more damaging than just setting a resolved address to zero.

Copy link
Member

Choose a reason for hiding this comment

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

Right, but the same goes for deploying it with an invalid address for ENS; either way, your only option is to redeploy the contract. Further, if we did have this check, it would cause the deployment to fail, leading to the exact same outcome - a moribund contract.


it.only('uses precise gas', function() {
return web3.eth.getTransactionReceiptAsync(resolver.transactionHash)
.then(receipt => assert.equal(receipt.gasUsed, 349348));
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this is a good test; it's brittle, and doesn't test anything useful.

Copy link
Contributor Author

@xavierlepretre xavierlepretre Mar 27, 2017

Choose a reason for hiding this comment

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

I see its usefulness in 2 places:

  • it informs on the gas requirements if another contract needs to deploy a resolver.
  • it ensures that the contract has no crazy gas requirement on deployment.


});

describe('has function', function() {
Copy link
Member

Choose a reason for hiding this comment

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

I have some bad news: has is obsolete, and is left in for legacy purposes. Thanks for testing it so thoroughly, though! :)

this.slow(200);
return resolver.setAddrAsync(utils.node, accounts[1], {from: accounts[0]})
.then(web3.eth.getTransactionReceiptAsync)
.then(receipt => assert.equal(receipt.gasUsed, 46163));
Copy link
Member

Choose a reason for hiding this comment

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

I don't think these precise gas tests are valuable either.

@Arachnid
Copy link
Member

Can you remove the 'exact gas' tests? Other than that, this looks great.

@Arachnid Arachnid merged commit d170ea1 into ensdomains:master Mar 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants