Investigate integration testing against an ethereum node

[dimroc]

As of now, we have two approaches:

1. Standard approach of creating a docker image with devnet or geth preconfigured with unlocked accounts to communicate with chainlink via JSONRPC over HTTP and ws.
2. Novel approach of staying entirely in the golang ecosystem and testing chainlink against geth inside goroutines in the same process, still using JSONRPC over HTTP and ws.

Let's discuss the pros and cons of each and perhaps come up with other ideas.

[se3000]

@toddboom what was that docker package you mentioned for spinning up docker containers from within a go program? Also, have you seen anyone use approach #2 before, spinning up multiple applications in one go test via goroutines and having them talk to one another?

[jordanbonilla]

Surprised no one else has ever taken approach 2 before? My intuition is that staying in the golang ecosystem would be ideal. It could potentially simplify the codebase.

[thodges-gh]

Also consider using Ganache-CLI which supports RPC. Using this, we may be able to get some testing deployment scripts to automatically complile & deploy our smart contracts on a local instance (within the Docker image).

[thodges-gh]

Since Ganache-CLI is out, I'm leaving this link here for me to check out later.

https://github.com/ethereum/go-ethereum/wiki/Private-network

It might not be until the weekend until I can really dive into it though. What I'm hoping for is we'll have a common config to use for the genesis block, and run it for testing in a (relatively) light-weight Docker image.

[toddboom]

@se3000 @dimroc Sorry, missed this last week. It looks like we weren't actually using a library in the example I mentioned to Steve, but instead just doing os.exec calls out to docker-compose to manage state and bring containers up and down during tests runs. It works pretty reliably and lets you manage your environment needs with a single .yml file.

I haven't seen a lot of instances of tests like #2, possibly because you might not always be able to spin up the things you need directly from go. (Or you may not be able to control them the way you'd like.) If those don't seem like concerns in this case, maybe it's worth exploring.

Let me know if you want more pointers on setting up a test harness for #1.

[dimroc]

Thanks @toddboom.

I want to capture some more information here for the sake of discussion.

Scenario 1: Docker Container

1. If you ever want to spin up more than one node, for example a miner and a relay node to experiment with gas bumping, it's much easier to stitch up or contain many nodes in docker containers than it is to do inside one app w multiple go routines.

2. I'm also a fan of separating the terminal output of each service rather than have multiple services share one stdout and spam up the screen.

Scenario 2: Geth Goroutine

1. It would be great to automatically share accounts (address, key) across chainlink and the node and not worry about syncing them up. Possible w 1) but not as seamless.

2. It seems like local development is going to be fairly dependent on block confirmations to either resume or finalize job runs. It would be nice to get this for free with some CLI in chainlink without having to spin up docker every time, but maybe that's unrealistic in the long term.

[dimroc]

After some more offline discussion we've opted go with scenario 1, with the key reasons being the desire to have separate processes, future proofing ourself against having to spin everything up in go routines when stitching up a network with the likes of geth, parity, btcd, ipfs, and being able to preconfigure each service to use the right ports and addresses.