TrueBlocks / trueblocks-core

The main repository for the TrueBlocks system
https://trueblocks.io
GNU General Public License v3.0
1.05k stars 198 forks source link

Testing in the presence of a cache #291

Closed tjayrush closed 7 years ago

tjayrush commented 7 years ago

We definitely want to remove all 'temporal' data from the 'gold test cases, but in the presence of a cache, this becomes complicated.

When one runs a test case for the first time (with ethslurp for example), the behaviour of the program is different than if one runs it thereafter. For example, ethslurp needs to download the transactions from http://etherscan.io the first time, but it reads that same data from its cache thereafter.

I think we need a CMakeLists.txt function called something like clearCacheEntry that takes an Ethereum address. It will simply delete the cache file so that each test case starts in the same state.

Here's a problem: some of the accounts we are using for testing may be accounts that I need for other (unrelated) work. If we remove the caches, my other code will have to re-create them. This is solved by using 'rare' accounts such as EEAR (use ethName -a EEAR to find address). EEAR was created about a year ago, and has not been used since.

You can tell if a test case has this problem by removing the file ~/.quickBlocks/slurps/ADDRESS.bin and ~/.quickBlocks/abis/ADDRESS.json or .abi prior to the test. If you get different results on the first run after deleting, than the second, this problem is here.

TODO: Write a function in CMakeList (or a python script -- I would prefer a python script so I can use it from the command line) to delete an address from the cache.

crodnun commented 7 years ago

OK Thomas, created today a python script under src/tools/scripts called clearCacheEntry.py. Review it and let me know if this is what you expected there.

Pushed to github after internal testing

It deletes for the moment files you specified above.

tjayrush commented 7 years ago

It's very easy to read, and it looks like it will work perfectly. As I find these types of issues, I will simply add this line to the start of the test case so we always start with the same state. I will close this now.