Skip to content
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

Merged
merged 4 commits into from
Apr 2, 2020

Conversation

jasontedor
Copy link
Member

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.

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.
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (:Core/Infra/REST API)

@@ -41,6 +42,45 @@

public class UsageServiceTests extends ESTestCase {

public void testNullHandler() {
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Member Author

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);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quality variable name! 👍🐴

Copy link
Member Author

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤣

@jasontedor jasontedor merged commit cdd07c5 into elastic:master Apr 2, 2020
jasontedor added a commit that referenced this pull request Apr 2, 2020
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.
@jasontedor jasontedor deleted the usage-service-validation branch April 2, 2020 12:56
@williamrandolph
Copy link
Contributor

Nice work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants