Painless unit testing

Elastic Stack Elasticsearch
1

I spent way more time last week than I would have liked to getting a few lines of painless script to work (not quite as painless as advertised). A lot of my pain came from having to relaunch our integration tests repeatedly. One thing I was wondering about is how to unit test this stuff.

On paper this stuff is perfect for unit testing: limited set of parameters and the output
is a double. Except, I'd need some way of running the script and getting my hands on the output and I haven't really found any.

So, Is there any way of doing this with a proper unit test that does not involve depending on a gazillion ES internals or having to write a full blown integration test against a running cluster?

Ideally, painless would be available as a separate dependency that people can just pull in and use in their unit tests or wherever.

2

One day you will be able to run painless outside of Elasticsearch but it won't have access to Elasticsearch's types then so every call to doc['foo'].value is going to do a different thing. You'd be able to much it up if you like but that won't catch differences between Elasticsearch's behavior and the mock. If that is ok with you then know that something is coming.

I don't think unit testing Elasticsearch and painless together is a thing that we'll support outside of the Elasticsearch project itself. Personally when I work on these issues I run Elasticsearch and use Kibana's dev tools to run the script over and over again. Once it is sound I move to to integration testing.

1 Like
3

I think it would be ok to not have direct access to elasticsearch internals. I'd expect to be mocking external things in any case using e.g. mockito in any case. The key thing is to be able to verify that scripts compile and run and produce expected ranking score given certain parameters.

4

Then you have to do nothing more than wait a while. We'll get there. But we're not sure when.

5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.

7

I was on a project recently where our java plugin was doing scripted updates and we were using ESClientYamlSuiteTestCase to handle our integration tests in yaml. They were failing as integTestCluster uses the stripped down integ-test-zip for the integration test node (it only ships with netty transport modules). I discovered setting the distribution to "zip" in integTestCluster in our build.gradle will load up a standard node with the common modules like lang-painless, etc.

 integTestCluster {
  distribution = "zip"
 }