embark/dapps/tests/app/test/config_spec.js

71 lines
2.0 KiB
JavaScript
Raw Normal View History

/*global embark, config, it, web3, before, describe*/
const {__} = require('embark-i18n');
fix(@embark/core): fix to allow large ether values Specifying large ether values in the configs was causing embark to crash as javascript could not handle the large integer after the value was converted to wei. The fix involves converting all values to BigNumbers and then comparing and adding/subtracting BigNumbers from that point forward. There are two specific components that this affected: `config/contracts > accounts > balance` and `config/blockchain > account > balance`. The contracts config is used to fund accounts for contract deployment while the blockchain config is used for dev_funds accounts. JSON.stringify unknown log messages Add a unit test in the test app that sets a large ether value in the config before contract deployment and ensures the account balance is the value specified in the config. Prior to this commit, if subsequent unit tests contained different account configurations, the blockchain VM was essentially reset, however EmbarkJS was hanging on to the old providers it used from the previous configuation. In addition, there is a limitation with `embark.registerActionForEvent` in that the action will be persisted across configuration changes. In our case, once the configuration was updated in a subsequent unit test, the directive subdomains would be attempted to be registered in ENS using the old configuration. This commit does two things: 1) It resets the EmbarkJS.Blockchain and EmbarkJS.Names providers to the new chain configuration 2) Update to the ENS directives that prevents attempts at registered configured subdomains for previous configurations.
2018-11-29 07:12:00 +00:00
const assert = require('assert');
let gasUsedForDeploy = 0;
let gasPrice = 1;
let accounts;
config({
blockchain: {
fix(@embark/core): fix to allow large ether values Specifying large ether values in the configs was causing embark to crash as javascript could not handle the large integer after the value was converted to wei. The fix involves converting all values to BigNumbers and then comparing and adding/subtracting BigNumbers from that point forward. There are two specific components that this affected: `config/contracts > accounts > balance` and `config/blockchain > account > balance`. The contracts config is used to fund accounts for contract deployment while the blockchain config is used for dev_funds accounts. JSON.stringify unknown log messages Add a unit test in the test app that sets a large ether value in the config before contract deployment and ensures the account balance is the value specified in the config. Prior to this commit, if subsequent unit tests contained different account configurations, the blockchain VM was essentially reset, however EmbarkJS was hanging on to the old providers it used from the previous configuation. In addition, there is a limitation with `embark.registerActionForEvent` in that the action will be persisted across configuration changes. In our case, once the configuration was updated in a subsequent unit test, the directive subdomains would be attempted to be registered in ENS using the old configuration. This commit does two things: 1) It resets the EmbarkJS.Blockchain and EmbarkJS.Names providers to the new chain configuration 2) Update to the ENS directives that prevents attempts at registered configured subdomains for previous configurations.
2018-11-29 07:12:00 +00:00
accounts: [
// you can configure custom accounts with a custom balance
2020-01-19 20:19:30 +00:00
// see https://framework.embarklabs.io/docs/contracts_testing.html#Configuring-accounts
fix(@embark/core): fix to allow large ether values Specifying large ether values in the configs was causing embark to crash as javascript could not handle the large integer after the value was converted to wei. The fix involves converting all values to BigNumbers and then comparing and adding/subtracting BigNumbers from that point forward. There are two specific components that this affected: `config/contracts > accounts > balance` and `config/blockchain > account > balance`. The contracts config is used to fund accounts for contract deployment while the blockchain config is used for dev_funds accounts. JSON.stringify unknown log messages Add a unit test in the test app that sets a large ether value in the config before contract deployment and ensures the account balance is the value specified in the config. Prior to this commit, if subsequent unit tests contained different account configurations, the blockchain VM was essentially reset, however EmbarkJS was hanging on to the old providers it used from the previous configuation. In addition, there is a limitation with `embark.registerActionForEvent` in that the action will be persisted across configuration changes. In our case, once the configuration was updated in a subsequent unit test, the directive subdomains would be attempted to be registered in ENS using the old configuration. This commit does two things: 1) It resets the EmbarkJS.Blockchain and EmbarkJS.Names providers to the new chain configuration 2) Update to the ENS directives that prevents attempts at registered configured subdomains for previous configurations.
2018-11-29 07:12:00 +00:00
{
privateKey: "random",
balance: "10 ether"
fix(@embark/core): fix to allow large ether values Specifying large ether values in the configs was causing embark to crash as javascript could not handle the large integer after the value was converted to wei. The fix involves converting all values to BigNumbers and then comparing and adding/subtracting BigNumbers from that point forward. There are two specific components that this affected: `config/contracts > accounts > balance` and `config/blockchain > account > balance`. The contracts config is used to fund accounts for contract deployment while the blockchain config is used for dev_funds accounts. JSON.stringify unknown log messages Add a unit test in the test app that sets a large ether value in the config before contract deployment and ensures the account balance is the value specified in the config. Prior to this commit, if subsequent unit tests contained different account configurations, the blockchain VM was essentially reset, however EmbarkJS was hanging on to the old providers it used from the previous configuation. In addition, there is a limitation with `embark.registerActionForEvent` in that the action will be persisted across configuration changes. In our case, once the configuration was updated in a subsequent unit test, the directive subdomains would be attempted to be registered in ENS using the old configuration. This commit does two things: 1) It resets the EmbarkJS.Blockchain and EmbarkJS.Names providers to the new chain configuration 2) Update to the ENS directives that prevents attempts at registered configured subdomains for previous configurations.
2018-11-29 07:12:00 +00:00
}
]
},
contracts: {
deploy: {
"Token": {
deploy: false,
args: [1000]
},
"MyToken2": {
instanceOf: "Token",
args: [2000]
},
"SomeContract": {
"args": [
["$MyToken2", "$accounts[0]"],
100
]
},
"SimpleStorage": {
args: [100]
}
fix(@embark/core): fix to allow large ether values Specifying large ether values in the configs was causing embark to crash as javascript could not handle the large integer after the value was converted to wei. The fix involves converting all values to BigNumbers and then comparing and adding/subtracting BigNumbers from that point forward. There are two specific components that this affected: `config/contracts > accounts > balance` and `config/blockchain > account > balance`. The contracts config is used to fund accounts for contract deployment while the blockchain config is used for dev_funds accounts. JSON.stringify unknown log messages Add a unit test in the test app that sets a large ether value in the config before contract deployment and ensures the account balance is the value specified in the config. Prior to this commit, if subsequent unit tests contained different account configurations, the blockchain VM was essentially reset, however EmbarkJS was hanging on to the old providers it used from the previous configuation. In addition, there is a limitation with `embark.registerActionForEvent` in that the action will be persisted across configuration changes. In our case, once the configuration was updated in a subsequent unit test, the directive subdomains would be attempted to be registered in ENS using the old configuration. This commit does two things: 1) It resets the EmbarkJS.Blockchain and EmbarkJS.Names providers to the new chain configuration 2) Update to the ENS directives that prevents attempts at registered configured subdomains for previous configurations.
2018-11-29 07:12:00 +00:00
}
}
}, (_err, web3_accounts) => {
accounts = web3_accounts;
});
// must be declared outside of the 'before' block, otherwise
// the 'block:header' event does not fire
embark.events.on("block:header", (blockHeader) => {
gasUsedForDeploy += blockHeader.gasUsed;
});
describe("Account balance", function() {
before(function(done) {
fix(@embark/core): fix to allow large ether values Specifying large ether values in the configs was causing embark to crash as javascript could not handle the large integer after the value was converted to wei. The fix involves converting all values to BigNumbers and then comparing and adding/subtracting BigNumbers from that point forward. There are two specific components that this affected: `config/contracts > accounts > balance` and `config/blockchain > account > balance`. The contracts config is used to fund accounts for contract deployment while the blockchain config is used for dev_funds accounts. JSON.stringify unknown log messages Add a unit test in the test app that sets a large ether value in the config before contract deployment and ensures the account balance is the value specified in the config. Prior to this commit, if subsequent unit tests contained different account configurations, the blockchain VM was essentially reset, however EmbarkJS was hanging on to the old providers it used from the previous configuation. In addition, there is a limitation with `embark.registerActionForEvent` in that the action will be persisted across configuration changes. In our case, once the configuration was updated in a subsequent unit test, the directive subdomains would be attempted to be registered in ENS using the old configuration. This commit does two things: 1) It resets the EmbarkJS.Blockchain and EmbarkJS.Names providers to the new chain configuration 2) Update to the ENS directives that prevents attempts at registered configured subdomains for previous configurations.
2018-11-29 07:12:00 +00:00
embark.events.request("blockchain:gasPrice", (err, blkGasPrice) => {
if (err) {
return done(new Error(__("could not get the gas price")));
fix(@embark/core): fix to allow large ether values Specifying large ether values in the configs was causing embark to crash as javascript could not handle the large integer after the value was converted to wei. The fix involves converting all values to BigNumbers and then comparing and adding/subtracting BigNumbers from that point forward. There are two specific components that this affected: `config/contracts > accounts > balance` and `config/blockchain > account > balance`. The contracts config is used to fund accounts for contract deployment while the blockchain config is used for dev_funds accounts. JSON.stringify unknown log messages Add a unit test in the test app that sets a large ether value in the config before contract deployment and ensures the account balance is the value specified in the config. Prior to this commit, if subsequent unit tests contained different account configurations, the blockchain VM was essentially reset, however EmbarkJS was hanging on to the old providers it used from the previous configuation. In addition, there is a limitation with `embark.registerActionForEvent` in that the action will be persisted across configuration changes. In our case, once the configuration was updated in a subsequent unit test, the directive subdomains would be attempted to be registered in ENS using the old configuration. This commit does two things: 1) It resets the EmbarkJS.Blockchain and EmbarkJS.Names providers to the new chain configuration 2) Update to the ENS directives that prevents attempts at registered configured subdomains for previous configurations.
2018-11-29 07:12:00 +00:00
}
gasPrice = parseInt(blkGasPrice, 10);
done();
});
});
it('should create an account balance from a large ether value in config', async function() {
const shouldBeWeiBN = web3.utils.toBN('1000000000000000000');
fix(@embark/core): fix to allow large ether values Specifying large ether values in the configs was causing embark to crash as javascript could not handle the large integer after the value was converted to wei. The fix involves converting all values to BigNumbers and then comparing and adding/subtracting BigNumbers from that point forward. There are two specific components that this affected: `config/contracts > accounts > balance` and `config/blockchain > account > balance`. The contracts config is used to fund accounts for contract deployment while the blockchain config is used for dev_funds accounts. JSON.stringify unknown log messages Add a unit test in the test app that sets a large ether value in the config before contract deployment and ensures the account balance is the value specified in the config. Prior to this commit, if subsequent unit tests contained different account configurations, the blockchain VM was essentially reset, however EmbarkJS was hanging on to the old providers it used from the previous configuation. In addition, there is a limitation with `embark.registerActionForEvent` in that the action will be persisted across configuration changes. In our case, once the configuration was updated in a subsequent unit test, the directive subdomains would be attempted to be registered in ENS using the old configuration. This commit does two things: 1) It resets the EmbarkJS.Blockchain and EmbarkJS.Names providers to the new chain configuration 2) Update to the ENS directives that prevents attempts at registered configured subdomains for previous configurations.
2018-11-29 07:12:00 +00:00
const actualBalanceWei = await web3.eth.getBalance(accounts[0]);
const actualBalanceWeiBN = web3.utils.toBN(actualBalanceWei);
const gasUsedWeiBN = web3.utils.toBN((gasUsedForDeploy * gasPrice).toString());
const totalBalanceWeiBN = actualBalanceWeiBN.add(gasUsedWeiBN);
assert.ok(totalBalanceWeiBN.gte(shouldBeWeiBN), "Total balance (account balance + deployment costs) should be greater than or equal to 100K ether");
});
});