Is there a test suite for colonyJS and if not is one planned?

I was looking to see if colonyJS had a test suite but I could not find one. Does one exist? If not is it planned?

The reason I ask is that I recently upgraded to a new a version and various things that should work are not working. In such cases, I could run the test suite to confirm the functions work and then compare my code to the tests to see what I am doing wrong. Each time I try to catch up to the latest versions I have these types of issues.

In this particular case, after using account 0xb77D57F4959eAfA0339424b83FcFaf9c15407461 to create a colony, I am trying to assign the ADMIN role to that same account like:

await client.setAdminRole.send({
    user: '0xb77D57F4959eAfA0339424b83FcFaf9c15407461'

Unfortunately it is reverting. In the old version I was able to assign OWNER and ADMIN without an issue this way.


Sorry, just found them Jest style in tests, but I still don’t see a test for this particular function… Thanks.

Hi, @ryanchristo. If a broader test suite is not currently available, in the short term do you have any idea why this setAdminRole could be reverting? I’ve tried various different ways. Would it revert if I was trying to set it to something it was already set to? What conditions could be causing a revert? Thanks for any insight.

Hey there!

First thing, the ADMIN role has the same permission as the FOUNDER role, so it might not be necessary to assign the account that created the colony (the FOUNDER) as an ADMIN unless you plan to transfer the FOUNDER role to another account. See Permissions for Colony Client methods.

That being said, you should still be able to set the account assigned the FOUNDER role as an ADMIN. This is currently possible in the colony-starter-react (soon to be renamed colony-example-react package). You can test it by running the following:

yarn global upgrade @colony/colony-starter
colony build colony-starter-react
cd colony-starter-react
yarn start-ganache
yarn deploy-contracts
yarn start-trufflepig
yarn start

This might be related to a mismatch in versions but the only reason I can think of for a revert error would be assigning the ADMIN role when calling the method from an instance of colonyClient where the account is not assigned the FOUNDER role (the account that created the colony).

The colony-starter-react package is currently using the following versions of colonyJS packages:

    "@colony/colony-js-client": "^1.11.2",
    "@colony/purser-metamask": "^2.1.1",

And the following version of colonyNetwork (the commit hash):


This commit hash includes the current version of the colonyNetwork smart contracts deployed to rinkeby and we will continue using this as the latest recommended version for the remainder of the month, then we will be upgrading to a new version of the colonyNetwork smart contracts once we deploy a new version to rinkeby (the version that will be the glider release - the first release on mainnet deployed the following month).

If you don’t want to install and run colony-starter-react, here is a minimal script you can test using the following versions of the colonyJS packages (assuming you have ganache running, the contracts deployed at commit 9bba127b0286708d4f8919526a943b0e916cfd7c, and trufflepig running):

    "@colony/colony-js-client": "^1.11.2",
    "@colony/purser-software": "^1.2.4",
const { getNetworkClient } = require('@colony/colony-js-client');
const { open } = require('@colony/purser-software');

(async () => {

  // Get a wallet instance (the private key of the first ganache test account)
  const wallet = await open({
    privateKey: '0x0355596CDB5E5242AD082C4FE3F8BBE48C9DBA843FE1F99DD8272F487E70EFAE',

  // Check out the logs to see the wallet address
  console.log('Wallet Address:', wallet.address);

  // Get a network client instance
  const networkClient = await getNetworkClient('local', wallet);

  // Check out the logs to see the network address
  console.log('Network Address:', networkClient.contract.address);

  // Create a token using the network client instance
  const { meta: { receipt: { contractAddress: tokenAddress } } } = await networkClient.createToken.send({
    symbol: 'TKN',

  // Check out the logs to see the token address
  console.log('Token Address: ', tokenAddress);

  // Create a colony using the network client instance
  const { eventData: { colonyAddress } } = await networkClient.createColony.send({

  // Check out the logs to see the colony address
  console.log('Colony Address:', colonyAddress);

  // Get a colony client instance using the network client instance
  const colonyClient = await networkClient.getColonyClientByAddress(

  // Set an admin using the colony client instance
  const tx = await colonyClient.setAdminRole.send({
    user: '0xb77D57F4959eAfA0339424b83FcFaf9c15407461',

  console.log('Transaction:', tx);

  .then(() => process.exit())
  .catch(error => console.error(error));

You might notice that I have not included the contract loader and adapter packages. The getNetworkClient method in the @colony/colony-js-client package is a new feature that I added last month that uses what would be the default configuration for getting the network client the old way (which still works the same).

Ok, I’ve released a beta of colony-cli and updated the other colonyStarter packages. setAdminRole is used in several of the packages but the smallest package to see a working example would be colony-starter (this is no longer a cli package but a simplified version of what was colony-starter-basic).

I would love your feedback and let me know if you need any help updating to the latest colonyJS. Cheers!

Hi, Ryan. I was able to get setAdminRole working by comparing my code with your examples.

The root cause of the problem was that because of some of the ColonyJS API changes, my old code did not throw any errors, but there was a silent “error” in the sense that how I previously set the Ethereum account through which I was interacting with the library was no longer getting set correctly and so the setAdminRole was being rejected because the request came through a non-authorized account.

One thing that may help with these kind of API changes is to run old versions of your example code through upgraded library APIs and address any failures, either silent or not. For silent errors, you could possibly add explicit errors thrown to alert people like me that are upgrading. The best would be to ensure backward compatibility except at major semver points.

Another thing that would be helpful would be to add revert messages so that it is clear why a reversion from Colony contracts is happening. I know Colony relies on dappsys contracts which may or may not have revert messages, but core ones that users are likely to encounter frequently (e.g. permissions related) might be added by extending or wrapping the dappsys functionality.

Thanks again for your help.

1 Like

This is a great idea and something we definitely will and have considered. We are working out the best solution for colonyJS to support upgradable colonyNetwork contracts and we will have something more refined soon after we officially launch on mainnet. Until then, keeping up-to-date with the latest version of colonyJS would be my best recommendation and we will do our best to provide a clear explanation of what needs to be updated in the release notes.

We will be making another significant update next week, which will be a colonyJS version that is compatible with the latest colonyNetwork contracts (a new version we will be launching on rinkeby and, if all goes well, it will be the version we launch on mainnet soon after). This version of colonyNetwork has additional revert errors but if there are any in particular that you are not seeing and would find helpful, feel free to open a PR.

Thanks again! Your feedback is greatly appreciated. Cheers.

1 Like