Skip to content
This repository was archived by the owner on Aug 20, 2025. It is now read-only.

Conversation

@nickwallen
Copy link
Contributor

@nickwallen nickwallen commented Jul 16, 2019

The SolrUpdateIntegrationTest is not testing that the SolrDao can update and retrieve values. This fix is similar to what was done for Elasticsearch in #1451.

This replaces #1454 which was a more involved refactor that fixed some issues with code duplication and provided additional unit tests. I am going to break-off just the bare minimum of what we need to fix the broken tests, rather than fix and refactor in the same PR.

What?

This gap in the integration test is hiding a couple bugs.

  1. A timestamp is not being populated in the documents returned from Solr.

  2. The integration test is not accounting for the fact that comments are serialized differently when written to Solr versus Elasticsearch. When comments are written to Solr, they are serialized as a list of JSON strings. When comments are written to Elasticsearch, they are serialized as a list of maps.

Why?

These problems arise because of the way the test is setup. Instead of directly testing a SolrDao this test runs against a MultiIndexDao initialized with both a SolrDao and an HBaseDao. On retrievals the MultIndexDao will return the document from whichever index responds first.

With the current test setup, the underlying SolrDao will never retrieve the document that the test case is expecting. In all cases where the test passes, the document is actually being returned from the HBaseDao which is actually just interacting with a mock backend. The test needs to actually test that we can update and retrieve documents from Elasticsearch.

Changes

  1. The SolrUpdateIntegrationTest was changed so that it specifically tests a SolrDao.

  2. The UpdateIntegrationTest was changed so that it can handle comments stored as either strings or maps. This allows the same integration tests to continue to work when run against either Solr or Elasticsearch.

Acceptance Testing

  • Validate against Elasticsearch.

    1. Spin-up Full Dev with Elasticsearch running.
    2. Ensure alerts are visible in the Alerts UI.
    3. Add a comment to an alert.
  • Validate against Solr.

    1. Spin-up Full Dev with Solr running.
    2. Ensure alerts are visible in the Alerts UI.
    3. Add a comment to an alert.

Pull Request Checklist

  • Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.
  • Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
  • Has your PR been rebased against the latest commit within the target branch (typically master)?
  • Have you included steps to reproduce the behavior or problem that is being changed or addressed?
  • Have you included steps or a guide to how the change may be verified and tested manually?
  • Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:
  • Have you written or updated unit tests and or integration tests to verify your changes?
  • If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
  • Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?

}


private SolrDocument createSolrDocument(String sensorType, Long timestamp) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Thank you for this - simple types like this should not be mocked. Good improvement.

solrDocument.addField(Constants.GUID, UUID.randomUUID().toString());
solrDocument.addField(Constants.SENSOR_TYPE, sensorType);
solrDocument.addField(Constants.Fields.TIMESTAMP.getName(), timestamp);
solrDocument.addField("ip_src_addr", "192.168.1.1");
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. Thanks

* as maps, so they look the same when validation occurs in the integration tests.
* @param fields
*/
protected static void reformatComments(Map<String, Object> fields) {
Copy link
Contributor

Choose a reason for hiding this comment

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

How about normalizeCommentsAsMap for a name?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That is more descriptive. Done.

@mmiklavc
Copy link
Contributor

Looks pretty good. A couple small nits and I think this is good to go.

@mmiklavc
Copy link
Contributor

+1 thanks @nickwallen

@asfgit asfgit closed this in ed63eac Jul 19, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants