-
Notifications
You must be signed in to change notification settings - Fork 410
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 tests naming section to CONTRIBUTING.md
#2816
Add tests naming section to CONTRIBUTING.md
#2816
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #2816 +/- ##
=======================================
Coverage 63.81% 63.81%
=======================================
Files 442 442
Lines 22519 22519
=======================================
Hits 14370 14370
Misses 7210 7210
Partials 939 939
Flags with carried forward coverage won't be shown. Click here to find out more. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great one! Let me know if anyone has suggestion or input!
6. Keep test names concise, avoiding overly cryptic names. Use abbreviations when appropriate. | ||
7. Avoid including test data in the name to maintain clarity and prevent excessively long names. | ||
8. Test case names should follow `TitleCase` capitalization style. | ||
9. Test and subtest names should not exceed 64 characters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition, 64 characters rule also adds pg
, sqlite
etc suffix, so it would be a bit shorter. 🙈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is about the test name segments
1. Test files should be named after the command they test. | ||
For example, `find_test.go` for testing the find command. | ||
Test files belonging to the same commands group are organized into folders named after this group, | ||
such as `aggregation`, `operations`, `diagnostic`, etc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we add a new folder, do we also need to modify Taskfile so that newly tests in folder are run? 🤔
I think this is a good organisation, but might add complications to adding test, and we want adding tests to be easy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point! Overall, there won't be a lot of folders and new folders won't be added too often, but I agree the process of adding new tests/folders should remain simple.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may also have impact on recent work about running integration tests in shard #2692
Anyway, I think we need to make sure everyone is onboard, if so then we need to make sure we have tooling in place to do it simply. 🤗
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should not be a problem with ./...
as long as test names are unique. Envtool should be able to check that
|
||
1. Test files should be named after the command they test. | ||
For example, `find_test.go` for testing the find command. | ||
Test files belonging to the same commands group are organized into folders named after this group, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a question to everyone, do we want a test file for each operator such as find_bitwiseanyset_compat_test.go
or are we happy grouping them in a same file with similar operators like now? Not sure how we've grouped them now but it makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest, I don't like the current approach of having everything in the same file because it's hard to navigate through the files that have 1000+ lines of code. If the files for different operators are separate, it's easier to go through them, scroll through the tests for a particular operator, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah agree. If we all agree let's document that too 🤗
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, find
, update,
aggregate
will be huge without additional level of splitting
such as `aggregation`, `operations`, `diagnostic`, etc. | ||
2. If the file contains compatibility tests, add the `_compat` suffix. For example, `find_compat_test.go`. | ||
3. Test names should include the name of the command being tested. | ||
For instance, `TestDistinct` for testing the distinct command. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finally, for RunCommand
do we have a preference? 🤔
Currently we have TestFindAndModifyCommand
, TestCommandsFindAndModify
, TestFindAndModifyRunCommand
, or just TestFindAndModify
because findAndModify can only be run as RunCommand
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, let's document this one too!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I don't know which one to use. Up to you to suggest, I'm always in for shortest name 🙈
|
||
1. Test files should be named after the command they test. | ||
For example, `find_test.go` for testing the find command. | ||
Test files belonging to the same commands group are organized into folders named after this group, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, find
, update,
aggregate
will be huge without additional level of splitting
1. Test files should be named after the command they test. | ||
For example, `find_test.go` for testing the find command. | ||
Test files belonging to the same commands group are organized into folders named after this group, | ||
such as `aggregation`, `operations`, `diagnostic`, etc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should not be a problem with ./...
as long as test names are unique. Envtool should be able to check that
If the test is checking for a specific error scenario, include the error scenario in the name. | ||
6. Keep test names concise, avoiding overly cryptic names. Use abbreviations when appropriate. | ||
7. Avoid including test data in the name to maintain clarity and prevent excessively long names. | ||
8. Test case names should follow `TitleCase` capitalization style. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some points, including that one, should clarify the difference between top-level test functions and subtests. For example, TestFind/Doubles
is a valid (full) test name, but not a valid test function name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should specifically mention that no spaces, dashes or underscores should be used anywhere
6. Keep test names concise, avoiding overly cryptic names. Use abbreviations when appropriate. | ||
7. Avoid including test data in the name to maintain clarity and prevent excessively long names. | ||
8. Test case names should follow `TitleCase` capitalization style. | ||
9. Test and subtest names should not exceed 64 characters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is about the test name segments
@rumyantseva this pull request has merge conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we close this one as we already added some naming guidelines?
Description
Closes FerretDB/engineering#66.
CONTRIBUTING.md
#2708 and the brainstorming we had after that.Readiness checklist
task all
, and it passed.@FerretDB/core
), Labels, Project and project's Sprint fields.