-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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 validation to the usage service #54617
Add validation to the usage service #54617
Conversation
Today the usage service can let in some issues, such as handlers that do not have a name, where the errors do not manifest until later (calling the usage API), or conflicting handlers with the same name. This commit addresses this by adding some validation to the usage service.
Pinging @elastic/es-core-infra (:Core/Infra/REST API) |
@@ -41,6 +42,45 @@ | |||
|
|||
public class UsageServiceTests extends ESTestCase { | |||
|
|||
public void testNullHandler() { |
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.
How do you feel about adding JavaDoc for these new test cases? We added something to the contribution guidelines about this, and I personally find it enormously useful to check that the stated purpose of the test matches the implementation.
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.
Also, and maybe this is just a preference, but I like to name my tests so that they contain the expectation - so testHandlerCannotBeNull
, or testHandlerMustHaveAName
, etc. Otherwise the test name says what the test is doing, but not what the outcome should be. There's overlap with the JavaDoc, but it might be useful in e.g. the Gradle UI.
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 added Javadocs, and I adjusted the name of testHandlerCannotBeNull
, but testAHandlerWithNoName
I'm keeping because it's a reference to a song, and it's fun.
|
||
public void testAHandlerWithNoName() { | ||
final UsageService service = new UsageService(); | ||
final BaseRestHandler horse = new MockRestHandler(null); |
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.
Quality variable 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.
Little slice of American pie right there. 😉
public void testHandlerWithConflictingNamesButSameInstance() { | ||
final UsageService service = new UsageService(); | ||
final String name = randomAlphaOfLength(8); | ||
final BaseRestHandler first = new MockRestHandler(name); | ||
service.addRestHandler(first); | ||
// nothing bad should happen | ||
// nothing bad ever happens to me |
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.
🤣
Today the usage service can let in some issues, such as handlers that do not have a name, where the errors do not manifest until later (calling the usage API), or conflicting handlers with the same name. This commit addresses this by adding some validation to the usage service.
Nice work! |
Today the usage service can let in some issues, such as handlers that do not have a name, where the errors do not manifest until later (calling the usage API), or conflicting handlers with the same name. This commit addresses this by adding some validation to the usage service.