Move to truffle 5

[JakeOShannessy]

It uses web3-1.0, and even the simplest cases go from 1000 ms to about 50 ms, and solves the issues I've been having testing with parity.

[JakeOShannessy]

With the previous version of web 3 is an issue where it didn't recognise that transactions had been completed using when using Parity with InstantSeal. This meant that the tests halted, waiting for a response. This could be avoid by sending other simultaneous requests to the Parity node at the same time to force more blocks to be mined, but it is excruciatingly slow.

[Latrasis]

Putting this on hold due to difficulty and low priority.

[JakeOShannessy]

Currently, when running tests with ganache they take about 6-7 minutes for me. How long do they take in other setups?

[JakeOShannessy]

Just to note here for when we need to discuss Web3 1.0 (which I believe is in Truffle 5) there is another big advantage. With the current Web3 version we need to pack the data ourselves when calling a procedure via the entry procedure. This is as follows:

const manualInputData = web3.fromAscii(procName.padEnd(24,"\0")) // the name of the procedure to call (24 bytes)
    + functionSelectorHash // the function selector hash (4 bytes)
    + web3.fromAscii(testProcName.padEnd(24,"\0")).slice(2).padEnd(32*2,0) // the name argument for register (32 bytes)
    + deployedTestContract.address.slice(2).padStart(32*2,0) // the address argument for register (32 bytes)
    + web3.toHex(124).slice(2).padStart(32*2,0) // the offset for the start of caps data (32 bytes)
    + web3.toHex(0).slice(2).padStart(32*2,0) // the caps data, which is currently just a length of zero (32 bytes)

With Web3 1.0 it does all of the ABI management for us and the code would be as follows:

try {
    console.log(deployedContract.methods.B(testProcName,deployedTestContract.address,[]).data)
} catch (e) {
    console.log(e)
}

[Latrasis]

Currently, when running tests with ganache they take about 6-7 minutes for me. How long do they take in other setups?

Same here. It is very slow. Refactoring the tests would be ideal of course, but I've been hitting bottlenecks in #86. I'll see if a rebase might help.