-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate StateTest format #487
Comments
Yes, definitely agree on 1, it's not good and it makes the definition of our types way more convoluted than it has to be, and this is just the result of us trying to adapt the existing fixture format without breaking anything. The use I see of the state test format is that you can test for rejected transactions more easily than in the blockchain test format: In the blockchain test format, if the cause of invalidation is an invalid transaction, you get a passing test if the client rejects the block, but if you want to make sure that it was rejected because the transaction was deemed as invalid (and not some other block validation error) you need to check the error string. In the case of the state test you check that the state hash did not change and then you can be sure the transaction was the cause of the rejection. IMO I think we need to standardize the block invalidation errors before phasing out the state test format. |
The t8n has the |
cc @holiman |
The multy transaction types are fillers only. When you parse the generated test you don't need to support it. Use txbytes field The state hash could be provided with full state no problem. |
The StateTest format has many disadvantages for users and is very close to the single-transaction BlockchainTest.
What is blocking us from using only BlockchainTests?
Disadvantages
The text was updated successfully, but these errors were encountered: