-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add type-level tests for launchTestNode
#2775
Comments
I would like to see a possible instance of such a regression, the scenario in #2756 cannot be re-introduced as it stands as the tagged union was necessarily narrowed , and should someone try to revert it to a tagged union, the compiler would throw an error on the contract function calls. Writing a test to catch problem such as the one in #2756 would be the equivalent of trying to do a contract function call on the tagged union, at which point the compiler would complain. My apprehension here is that we are doing double work, when we should just leverage the compiler. I only see such a test offering a benefit when interacting with javascript directly. |
@danielbate the problem is that we're not doing compile-time checks in our test suite, hence the usage across the repo doesn't prevent us from introducing a breaking change in the types. We either do that or we create specific tests that we'd run |
@danielbate #2941 modifies the typegen outputs and is unrelated to this issue except that they both touch on type-level tests. This one is related to |
Conceptually, you can introduce changes to a type that would still allow the compiler to compile the code successfully but that would introduce a regression as the type is not the intended one. The only way to guard against that is via type-level tests which assert that, for a given set of concrete inputs, the type inference logic returns the exact expected outputs. These type-level tests would be "green" if the compiler successfully compiles them.
We need such type-level tests so that we can catch problems like the one fixed in #2756.
The text was updated successfully, but these errors were encountered: