Variable in Smart contract in ganache is not updated

[pstrotmann]

Truffle Ticket #702341 [Pending] Support Ticket sent from peter@strotmann.org in HubSpot - Truffle

All you need to reproduce the Issue is contained in the repo:

https://github.com/pstrotmann/SimpleStorage

I would expect storedData = 17 in my smart contract after running simple_storage.js because the assert after calling

// set simpleStorage
   await simpleStorageInstance.set.sendTransaction(17, { from: accounts[0] });
   simpleStorageInstance.set.sendTransaction(17, {from:accounts[0]});

// Get stored data
    const storedData = await simpleStorageInstance.get();

    assert.equal(storedData, 17, "The value 17 was not stored.");

indicates that 17 is stored in storedData.

Therefore I would expect that the 17 is stored persistent in SimpleStorage contract. But as You see in ganache there is 0.

The 3 steps I performed (see hardcopies in obove repo) were:

1) truffle deploy (to deploy the contract SimpleStorage, as you see in ganacheTest/console/truffleDeploy.png)

2) truffle test ./test/simple_storage.js (to test setting storedData = 17 in contract SimpleStorage, as you see in ganacheTest/console/truffleTestSimpleStorageJs.png)

3) truffle test ./test/simple_storage.sol (to test setting storedData = 18 in contract SimpleStorage, as you see in ganacheTest/console/truffleTestSimpleStorageSol.png)

As you see from the hardcopies deploy and the tests succeeded either.

You also see from the harcopies named worspace... what happened due to deploying and testing on the ganache blockchain on the account, the blocks, transactions and the contract after each of the above steps.

Without the update facility of smart contracts in truffle/ganache testing contracts does not make real sense making truffle/ganache quite worthless.

[eggplantzzz]

Hey @pstrotmann! The behavior you specify above is correct and expected. Ganache has a special rpc method for reverting state. While running truffle test, Truffle at different points resets the state of the chain to what it previously was as this is very useful for testing. Relevantly, one of those times is at the end of running the test suite. So I would expect the chain to be in the state it was in when you started the tests. If you run against another chain like Geth (which does not support this special rpc method), however, it would be typical for the chain state to have mutated.

If you do the same calls to set the variable in your migrations you will get an altered chain state as there is no mechanism for resetting the chain state involved in running the migrations.

[pstrotmann]

do not agree with you that rollback at the end of test suite is the desired behavior. A successful transaction instead should follow the ACID paradigm with the D meaning durable as default. At least the user should have the choice rollback or not.

As you indicated in your last sentence there is a means to have such a choice using migrations. But unfortunately I do not understand how that works. It would be helpful, if you give me some explanation how to.

[eggplantzzz]

truffle test is meant for running automated tests. Teardown/cleanup is a common, standard part of automated testing and helps ensure that you can write tests without worrying about state changing all the time between tests etc. This allows you to consistently get deterministic results, especially when adding more tests to your test suite that may mutate state as well. If you'd like to request a feature to turn this off, please submit an issue in the Truffle repo! We're always glad to hear about what features you all want.

You can also just open up a Truffle development console and interact with your contracts that way as well. You should check out the Truffle docs; here are the docs for running migrations. But it now sounds like the Truffle development console might be an easier way for you to interact with your contracts (though you will have to run migrations while using it to deploy your contracts before you can interact with them). Truffle development console docs are here.

[pstrotmann]

neither of the two suggestions meets my needs. Using truffle console makes no difference than saying truffle from outside the console. Using migrations is just setting variables at deploy time, no dynamic setting of contracts possible.

I give up

[eggplantzzz]

Hey @pstrotmann, what exactly are your needs? I thought you were just reporting what you thought was a bug. Let me know what you are interested in accomplishing and I can try and help. The console allows you to deploy and interact with your contracts if that is what you are interested in.

[pstrotmann]

an option --norollback in the test command would meet my needs completely

[eggplantzzz]

In the meantime, tell me what you want to happen in general and maybe I can give you a workaround. Like, what are your needs?

[pstrotmann]

What do you mean with meantime ? Is it the time until test --norollback is implemented ? If that time is under 3 months there is no need for a workaround.

[eggplantzzz]

I do not know if/when we will implement that feature but we will put it in the backlog for consideration. So to be clear, your needs are that you want to be able to programmatically test your truffle project and have the test network state never revert. Is that correct? The testing flow is the only time where such state reversions happen.

[alizdd]

I agree with @pstrotmann , I was confused and lost time when I see no changes in ganache interface, with norollback option, that would be better test experience imo

[amva13]

to be clear -- is this also the reason the state seems to rollback during webapp testing with react. say I have a setter and a getter. I call the setter first and everything seems to work and console.log reflects the change in ganache. I call the getter but the variable is now back to its initial state. as @eggplantzzz mentioned, doing everything from truffle develop works perfectly. from react webapp, rollback seems to happen after an individual contract function call instead. is a react function call treated as an individual test here ? if so, I think a no rollback option would be useful for webapp testing. I agree with @eggplantzzz rolling back after an individual test is desired behavior for automated testing suites.