Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delete redundant tests #621

Merged
merged 4 commits into from
Apr 26, 2023
Merged

Delete redundant tests #621

merged 4 commits into from
Apr 26, 2023

Conversation

richardpringle
Copy link
Contributor

Why this should be merged

Will make changes in #601 easier to read/reveiw

How this works

Just deleting tests that are redundant or failing

How this was tested

N/A

How is this documented

N/A

it("should add contract deployer as owner", async function () {
const contractOwnerAddr: string = await contract.owner()
expect(owner.address).to.equal(contractOwnerAddr)
});
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Testing the OpenZeppelin modifier, nothing to do with precompiles or our code.

Copy link
Contributor

Choose a reason for hiding this comment

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

Agree

return
}
expect.fail("should have errored")
});
Copy link
Contributor Author

Choose a reason for hiding this comment

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

addDeployer isn't a contract function, so this test really isn't testing anything. The allowlist logic is already tested.

Copy link
Contributor

@anusha-ctrl anusha-ctrl Apr 25, 2023

Choose a reason for hiding this comment

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

So, bit confused here. It seems like we define addDeployer in tasks.ts. The definition of addDeployer is as follows and does test the allow list logic here. Correct me if I'm wrong.

task("deployerAllowList:addDeployer", "Adds the deployer on the allow list")
  .addParam("address", "the address you want to add as a deployer")
  .setAction(async (args, hre) => {
    const allowList = await hre.ethers.getContractAt("IAllowList", CONTRACT_ALLOW_LIST_ADDRESS)
    // ADD CODE BELOW
    await allowList.setEnabled(args.address)
    await getRole(allowList, args.address)
  })

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have no idea what those tasks are. But they aren't used when the code is run for the e2e tests. All of those addDeployer methods fail with some kind of method does not exist error.

Copy link
Contributor

Choose a reason for hiding this comment

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

Interesting

Copy link
Contributor

Choose a reason for hiding this comment

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

https://hardhat.org/hardhat-runner/docs/advanced/create-task Read more about tasks here. Seems to be used by hardhat as a cli command. These should be removed 👍

return
}
expect.fail("should have errored")
});
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Another addDeployer

Copy link
Contributor

Choose a reason for hiding this comment

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

Same as above

return
}
expect.fail("should have errored")
});
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Another addDeployer

return
}
expect.fail("should have errored")
});
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is testing logic in the example contract, not the precompile. There's nothing in the precompile that prevents an admin from "revoking" itself.

return
}
expect.fail("should have errored")
});
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same comment as above.

it("should add contract deployer as owner", async function () {
const contractOwnerAddr: string = await contract.owner()
expect(owner.address).to.equal(contractOwnerAddr)
});
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same thing, no need to test OpenZeppelin logic.

Copy link
Contributor

Choose a reason for hiding this comment

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

Agree

return
}
expect.fail("should have errored")
})
Copy link
Contributor Author

Choose a reason for hiding this comment

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

addDeloyer isn't a function.

Copy link
Collaborator

Choose a reason for hiding this comment

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

hmmm so these were failing but with wrong errors. totally bad testing...
good catch 👍

return
}
expect.fail("should have errored")
})
Copy link
Contributor Author

Choose a reason for hiding this comment

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

allowed can't revoke anyone including itself. Blocking a non-admin is already tested.

return
}
expect.fail("should have errored")
})
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This tests a require statement in the example contract. The precompile doesn't have this functionality and is thus testing the EVM bytecode generated by the solidity compiler instead of testing the precompile(s).

@richardpringle richardpringle marked this pull request as ready for review April 24, 2023 16:52
Comment on lines -122 to -141
it("signer1 should be appointed as reward address", async function () {
let tx = await contract.setRewardAddress(signer1.address);
await tx.wait()
let rewardAddress = await contract.currentRewardAddress();
expect(rewardAddress).to.be.equal(signer1.address)
});

it("signer1 should be able to receive fees", async function () {
let previousBalance = await ethers.provider.getBalance(signer1.address)

// Send a transaction to mine a new block
const tx = await owner.sendTransaction({
to: signer2.address,
value: ethers.utils.parseEther("0.0001")
})
await tx.wait()

let balance = await ethers.provider.getBalance(signer1.address)
expect(balance.gt(previousBalance)).to.be.true
})
Copy link
Collaborator

Choose a reason for hiding this comment

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

why have we removed those? these are testing the actual logic in reward manager precompile.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh weird, I swear I left a comment here before.

My assumption here was that the test was redundant as I thought that balance was stored the same way for contracts and EOAs. But after a little digging, looks like I'm wrong. Will fix!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, after looking again at the new DS-Tests, the logic is exactly the same. I don't think these tests are necessary. More granular testing unit/integration testing should happen for the Go code, but I think testing that "an address" is set as the reward-address and that the same address has an increased balance after a transaction single transaction is mined is sufficient.

Copy link
Collaborator

Choose a reason for hiding this comment

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

ah ok that was a redundant test. Some tests were put to clear possible confusions like "reward address should be same address as the wrapping contract" etc. so specifically put that one to show EOAs & contracts can both be reward address. but thats a reduntant test indeed.

return
}
expect.fail("should have errored")
})
Copy link
Collaborator

Choose a reason for hiding this comment

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

hmmm so these were failing but with wrong errors. totally bad testing...
good catch 👍

Copy link
Contributor

@anusha-ctrl anusha-ctrl left a comment

Choose a reason for hiding this comment

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

lgtm

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

Successfully merging this pull request may close these issues.

5 participants