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

Branded token and Gateway composer interact with unit tests. #99

Merged
merged 19 commits into from
Feb 22, 2019

Conversation

0xsarvesh
Copy link
Contributor

@0xsarvesh 0xsarvesh commented Feb 18, 2019

Fixes #82 and #83

Added branded token contract and gateway composer contact interacts with unit tests.
Refer contract from here and here

@0xsarvesh 0xsarvesh self-assigned this Feb 18, 2019
@0xsarvesh 0xsarvesh changed the title Branded token interact with unit tests. Branded token and Gateway composer interact with unit tests. Feb 19, 2019
Copy link
Contributor

@schemar schemar left a comment

Choose a reason for hiding this comment

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

I did not check the tests, the other comments should be addressed first.

In addition to in-line comments:

  • A lot of JSDoc is missing the {type} annotation.
  • The contract interacts should also have getters for the public variables.
  • It would have been nicer to have one PR per contract interact.

.travis.yml Outdated Show resolved Hide resolved
this.liftRestrictionRawTx = this.liftRestrictionRawTx.bind(this);
this.isUnrestricted = this.isUnrestricted.bind(this);
this.rejectStakeRequest = this.rejectStakeRequest.bind(this);
this.rejectStakeRequestRawTx = this.rejectStakeRequestRawTx.bind(this);
Copy link
Contributor

Choose a reason for hiding this comment

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

missing (from https://github.com/OpenSTFoundation/brandedtoken-contracts/blob/develop/contracts/BrandedToken.sol):

  • liftAllRestrictions
  • revokeStakeRequest
  • redeem
  • setSymbol
  • setName
  • transfer
  • transferFrom
  • convertToValueTokens

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Intentionally skipped, as they are not used currently and of low priority for now.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hm... Is there another ticket for them? How do we communicate the lack of methods to the consumer?

Copy link
Contributor Author

@0xsarvesh 0xsarvesh Feb 21, 2019

Choose a reason for hiding this comment

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

Refer #104
Note: There is a default way to access all the contract methods by contractInteract.contract.methods.xyz
Note should be added in the readme that for a missing method of contract interact use contractInteract.contract.methods.xyz

Copy link
Contributor

Choose a reason for hiding this comment

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

Is there another ticket for the getters of public variables? They are also missing from other ContractInteracts.

lib/ContractInteract/BrandedToken.js Outdated Show resolved Hide resolved
lib/ContractInteract/BrandedToken.js Outdated Show resolved Hide resolved
lib/ContractInteract/BrandedToken.js Outdated Show resolved Hide resolved
utils/Utils.js Outdated Show resolved Hide resolved
utils/Utils.js Outdated Show resolved Hide resolved
utils/Utils.js Outdated Show resolved Hide resolved
utils/Utils.js Outdated Show resolved Hide resolved
* @returns {Promise} Promise object.
*/
static async sendTransaction(tx, txOption) {
return new Promise(async (onResolve, onReject) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it really required to construct a new promise instead of using the one from tx.send()?

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 am not sure, I have taken this from mosaic.js

Copy link
Contributor

Choose a reason for hiding this comment

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

It seems redundant to me 🤔

PR feedback changes for documentation

Co-Authored-By: sarvesh-ost <[email protected]>
@0xsarvesh
Copy link
Contributor Author

I did not check the tests, the other comments should be addressed first.

In addition to in-line comments:

  • A lot of JSDoc is missing the {type} annotation.
  • The contract interacts should also have getters for the public variables.
  • It would have been nicer to have one PR per contract interact.

I am bit surprise for the feedback changes in below files. Below files are directly taken from mosaic.js. Why these were not fixed there 😱

  1. AssertAsync
  2. Spy
  3. Utils

Copy link
Contributor

@abhayks1 abhayks1 left a comment

Choose a reason for hiding this comment

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

Overall looks good to me 💯. Learned more on writing JS unit tests using sinon 🤓 .
I have requested few changes. I think considering repetitive samilar validations we can refactor it to validation library/util. We should discuss this and implement it if everyone agrees.

* @param {Object} web3 Web3 object.
* @param {string} address BrandedToken contract address.
*/
constructor(web3, address) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we call web3 => "originWeb3" as BT is deployed on origin chain?

Copy link
Contributor

Choose a reason for hiding this comment

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

In my opinion, the BrandedToken class is not concerned with what's origin or auxiliary. It only cares that it is deployed on a chain that it can access with a web3 object.

Copy link
Contributor

Choose a reason for hiding this comment

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

no, rather moving it to web3 from where it is specified (and ambivalent)

* instance that has been deployed.
*/
static async deploy(
web3,
Copy link
Contributor

Choose a reason for hiding this comment

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

unit test for deploy and deployRawTx method is missing 👁

Spy.assert(spyRawTx, 1, [[stakeRequestHash, r, s, v]]);
sinon.restore();
});
it('should throw an error when stakeRequestHash is invalid', async () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

New line before it is missing 👀

const err = new TypeError('Invalid transaction options.');
return Promise.reject(err);
}
if (!Web3.utils.isAddress(txOptions.from)) {
Copy link
Contributor

@abhayks1 abhayks1 Feb 21, 2019

Choose a reason for hiding this comment

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

Since the validations for typechecks are repetitive, I think we should create Validation library/util where we can refactor the code. Validation library/util can also be used in mosaic.js and openst.js also. @schemar What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

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

That could help 👍

* @param {Web3} web3 Web3 instance that points to origin.
* @param {string} address Gateway composer contract address.
*/
constructor(web3, address) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we rename web3 to originWeb3 as GatewayComposer is deployed on origin chain?

* @param txOptions Transaction options.
*
* @returns {Promise<Object>} Promise that resolves to transaction receipt.
*/
Copy link
Contributor

Choose a reason for hiding this comment

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

We should mention in documentation as dev note that "requestStake is called by staker after GC is approved for ValueToken."

const err = new TypeError(`Invalid nonce: ${nonce}.`);
return Promise.reject(err);
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Please add below validations:
"Gateway address can't be 0x000000..."
"Beneficiary address can't be 0x000000..."

Should we validate that:
"Converted stakeVT should be equal to mintBT"
There will be a geth call need for that. To avoid get call, we can have a simple conversion logic in javascript.

if (!(conversionRate > 0)) {
throw new TypeError(`Invalid conversion rate: ${conversionRate}. It should be greater than zero`);
}
if (!(conversionRateDecimals < 5)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

The check should be "<=" because ConversionRateDecimals can be less/equal to 5.

conversionRateDecimals <= 5

return Promise.reject(err);
}

const mintedAmount = await this.convertToBrandedTokens(stakeAmount);
Copy link
Contributor

@abhayks1 abhayks1 Feb 21, 2019

Choose a reason for hiding this comment

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

I believe requestStake interface should be aligned with BrandedToken.requestStake.
So mintAmount should not be calculated in this function. It causes an extra geth call and updates the interfaces. Staker can call convertToBrandedTokens to know the mint amount.

* @param {Object} web3 Web3 object.
* @param {string} address BrandedToken contract address.
*/
constructor(web3, address) {
Copy link
Contributor

Choose a reason for hiding this comment

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

In my opinion, the BrandedToken class is not concerned with what's origin or auxiliary. It only cares that it is deployed on a chain that it can access with a web3 object.

const err = new TypeError('Invalid transaction options.');
return Promise.reject(err);
}
if (!Web3.utils.isAddress(txOptions.from)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

That could help 👍

* @param conversionRateDecimals The value to which
* conversionRateDecimals is set.
* @param organization Organization contract address.
*
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't find @dev as a valid JSDoc annotation. It would also not be correct as this info is not intended for developers, but for consumers of the function and should therefore not be hidden behind @dev.
Why don't you explain the parameters where they're supposed to be explained?

throw new TypeError(`Invalid conversion rate decimal: ${conversionRateDecimals}. It should be less than 5`);
}

const abiBinProvider = new AbiBinProvider();
Copy link
Contributor

Choose a reason for hiding this comment

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

Then pass it as an argument to the static method. Alternatively pass the bin.

/**
* Raw tx for request stake.
*
* @param {string} stakeAmount Stake amount.
Copy link
Contributor

Choose a reason for hiding this comment

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

A lot of the methods could use better documentation. For example: the stake amount as a decimal or as an integer with the decimals included?

*
* @param {Object} spy Spy object for a function.
* @param {number} callCount number of times the function was called.
* @param {Array} inputArgs Two dimensional array where each one
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* @param {Array} inputArgs Two dimensional array where each one
* @param {Array[]} inputArgs Expected input arguments to each call. Array of calls that contains an array of call arguments of each call.

* This compares values of two arrays index by index.
*
* @param {Array} actualArguments The First array which represents the actual
* value in the assertion.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* value in the assertion.
* values in the assertion.

* @param {Array} expectedArguments The second array which represents the
* expected value in the assertion.
*/
static assertArguments(actualArguments, expectedArguments) {
Copy link
Contributor

Choose a reason for hiding this comment

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

You are mixing concepts here. assertArguments is actually nothing else than assert.deepEqual(), which is independent from arguments. The fact that the arrays passed to the method are arguments shouldn't concern a function that does array equality check. Anyways, it seems we don't need this method and can replace it with assert.deepEqual()?


/**
* This class includes the functions shared among various classes.

Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change

* @returns {Promise} Promise object.
*/
static async sendTransaction(tx, txOption) {
return new Promise(async (onResolve, onReject) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems redundant to me 🤔

Copy link
Contributor

@benjaminbollen benjaminbollen 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.

4 participants