OnTrack – Ethereum Dapp – Part 2 – Smart Contract Testing


Hello, I am Loredana and today I will show
you how to set up your local environment for
testing smart contracts, using Mist and Remix.
I have recently started building decentralized
apps with Ethereum and wanted to share some
insights about the process.
To learn more about the OnTrack contract that
I will be testing today, check out the Part
1 video of the series.
We will first set up a private Ethereum node
and then we will also connect to the Ethereum
main Testnet node, which, at this point in
time, is the Ropsten Revival fork.
So, private node.
You will have a link to a gist with the commands
in the description.
You can also use testrpc for this, but now
I am using geth directly.
We first set up the private node.
I’ve already made beforehand the privtest
folder where the chaindata will be kept.
Let’s look a bit at these options.
ipcpath is the path to the local pipe that
geth creates, so that other processes can
comunicate with it.
We will use this to open a geth console in
another terminal.
We also give the path to the custom data directory.
Notice also the –dev tag, because we want
a private node for development.
We then have some tags to set up the JSON
RPC connection if we need it for connecting
our webapp.
Check the docs for more details on that.
Ok, now we can open Mist and we can actually
do it by passing the .ipc socket file path
to the –rpc tag, like this.
This just sets the –ipcpath option automatically.
Let’s do a geth attach in another tab, to
have access to the JavaScript console.
Mist is up, I already have accounts here.
We
are opening Remix to test the OnTrack contract.
Here it is.
So, as I said in my last video, it receives
a deadline in milliseconds (I’ve set it
to 10 min from now), the address of a provider
and the address of an already published observer
contract.
Don’t forget the quotes for the addresses.
We also assign ether to the contract from
here.
And we choose the ether account from here.
We have … ether on this account now.
By the way have access to the compiled contract
data.
To publish this contract from a web app, we
need it’s ABI (application binary interface)
and binary data.
You actually have the code here.
I used this in my example web app because
now web3.js does not have an option for compiling
Solidity code through RPC.
Only through IPC.
Let’s create it.
Now, we need to start mining for the transaction
to take place.
And here it is.
We also see that the account has less ether.
Now we can change accounts.
We are the provider, with … ether in the
account.
We click complete.
Change accounts again and
click on confirm, which means the contract
was indeed fulfilled.
And we see that the provider has received
the 0.3 ether.
We may see that our transactions consume a
lot more gas that expected.
This can be due to code inefficiency and it
is something that I also have to learn more
about.
The events that we see here were specifically
defined in the code here.
As i told you, they are a good way to log
your code and you can also use them from your
web application, through the web3.js API.
Let’s do one more test where the provider
completes the project, but does not receive
a confirmation from the client.
I will put the deadline to be 1 min from now.
Contract was created.
Provider announced completion and waits for
the deadline to end.
If we try to requestFunds now, we will get
an error (read).
So, if you encounter this error, don’t up
your gas limit.
It just means that either something is wrong
with your code or someone tried a forbidden
transaction and it got thrown out.
Now, the observer that we are using is programmed
to always return true, which means the project
is fulfilled.
So, we expect the provider to get his ether.
We requestFunds and watch.
We see the provider got his money.
Ok.
Ropsten Test net.
Let us close these and run geth with the testnet
tag.
We also open Mist with the appropriate ipc
socket file.
This should not be necessary, as you should
be able to choose Testnet from Mist.
But I had some issues with that.
It kept connecting to the original
Ropsten fork.
In a gist linked in the description you have
some instructions to set up your node in case
you keep connecting on the wrong fork and
also a way to test if you are on the right
one by comparing block hashes.
Again, the same IDE and we can see our Ropsten
accounts this time.
Of course, we have to change the provider
and observer addresses if we want to test
the contract here.
This is not a local node anymore, so it will
take longer for transactions to complete,
but you don’t have to mine them yourself.
That’s it!
Thank you for watching and do check out my
other demos.

Add a Comment

Your email address will not be published. Required fields are marked *