-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
tests: Make all table driven tests tell you where they failed #1664
Labels
Comments
Big ++ to this - super frustrating |
Good idea, let's start doing this! |
ValarDragon
added a commit
that referenced
this issue
Jul 16, 2018
Make table driven tests in /types follow the format described in #1664
8 tasks
Lets document this somewhere in contributing.md, and require this of all new tests that get written in future PR's. |
rigelrozanski
pushed a commit
that referenced
this issue
Jul 16, 2018
* types: Switch table driven test error messages to new format Make table driven tests in /types follow the format described in #1664 * typos / lower case errors * lower case, not sentences * lower case, not sentences
@ValarDragon want to add to contributing.md and then close this issue? |
Sure! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the majority of our table driven tests don't tell you where exactly they failed. (This is true of most tests in types, random example: https://github.com/cosmos/cosmos-sdk/blob/master/types/rational_test.go#L57) This makes debugging extremely hard. We definitely need to do something in the spirit of telling you which test case faiiled, however this doesn't need to be prelaunch, could easily be pre1.0.
Here is an example of a test case in something I created:
This makes it easy to figure out what you're looking at (as opposed to just a pile of different bytes in a file with many tests), and exactly which test case failed.
The above is actually not ideal. Here I propose is a more ideal way which we standardize throughout the sdk.
(Newline doesn't matter, was just including for ease of reading in the PR)
where
<desc>
is a short description which indicates what the objs are (since you don't have variable names), and what is failing. The indices that specify where it occured can be as simple as "i" and "j" in the for loop, or the variable name.A sample log output of the above would be:
The idea is that it should be easy to go from failed test case to where exactly the error occured, as line number doesn't tell you what test case, or what part of the test case. (In many cases, you run a for loop some amount of iterations) This would save debugging time significantly, when you're breaking an already existing thing.
The text was updated successfully, but these errors were encountered: