Unit test suite proposal

[cgewecke]

What follows is an outline for one approach to developing solcover's test suite. (Not wedded to any of it - additions / deletions / modifications are more than welcome ). Also submitting a draft PR with this issue because having a larger test base might make it easier to evaluate both this idea and some of the other recently proposed changes.

• Move solidity snippets for tests into their own .sol files and write some helper methods to load them into the suite. This will make it easier to add tests and allow you to run solcover against contracts that exist in the wild and check that these compile correctly (This idea borrowed from some of @duaraghav8 's tests of multi-line constructs for the Solium linter).
• Follow the example of ifStatements.js and write tests to verify that the instrumentation does not break the target contracts.
• Using Istanbul's unit tests as a model, begin developing tests for coverage accuracy.
• Begin launching tests via npm test and handling mocha options like timeout there. e.g. mocha --timeout 10000

Under this proposal the test directory structure would look something like this:

|-- test
   |-- util
        |-- util.js 
   |-- sources 
        |-- function
             |-- abstract.sol
             |-- empty-body.sol
             |-- ...
        |-- if
             |-- if-with-brackets.sol
             |-- if-without-brackets.sol
             |-- ...
        |-- zeppelin
             |-- Killable.sol
             |-- Shareable.sol
             |-- ...
        |-- ...
   |-- if.js
   |-- function.js
   |-- ...

A typical unit test that checks compilation would look like this:

it('should compile after instrumenting if statements with brackets',function(){
    var contract = util.getCode('if/if-with-brackets.sol');
    var info = getInstrumentedVersion(contract, "test.sol", true);
    var output = solc.compile(info.contract, 1); 
    util.report(output.errors);
})

[cgewecke]

Closing via #8