REST testing scripts

(Ivan Brusic) #1

Working on some code that I would like to test via the REST layer. The
default plugins are not loaded during integration testing, so when attempt
to use put_script:, I get the following error:

"unable to put stored script with unsupported lang [painless]"

Testing for painless and mustache, both scripts, occur within their
respective modules, which load the plugin during testing. My feature is
across all scripts, so adding tests to lang-painless or lang-mustache is
not ideal. I now see why there was no testing done on the generic REST
endpoint. :slight_smile: What would be the best way to test the ScriptService? This
code is a feature for the elasticsearch repo, not external code.



(Alexander Reelsen) #2

hey Ivan,

if you want to unit test, you need to create mocks/stubs for your services.

The other thing to do is write real integration tests, where you can fire up the elasticsearch cluster with the needed plugins enabled, and then you can either run YAML rest tests against this or write your own java test that uses HTTP.


(Ryan Ernst) #3

Normally to test scripting features in core, we would use a MockScript. See uses of MockScriptEngine and MockScriptPlugin in various unit tests.

(Ivan Brusic) #4

As I mentioned at the end of my post, I am testing code within the main
Elasticsearch repo. Judging by the lack of rest tests for the get scripts
endpoint, it seems like it is not possible via a workaround. For now, I put
my tests in the lang-painless module even the the code/tests are
independent of script language. Not sure that creating a module that
contains nothing by tests for code in core would be a good idea.

(Ryan Ernst) #5

@Ivan I think this is a deficiency in our current rest tests. We have the integ-test-zip distribution for the purpose of testing plugins as isolated as possible, but this also means the setup is less realistic. You could suggest in an issue that we run the rest tests (the server level ones, not individual plugins own rest tests) with the full zip distribution (which I would be in favor of, but we would need to move them around a bit as currently they are run inside the integ-test-zip project).

(Ivan Brusic) #6

Thanks Ryan, the was my takeaway from exploring the code. Would hate to see
another flurry of tests against a full distribution since the existing
tests already kill my laptop as is! I cannot see this issue being very
common, so do not think it should requiring such a refactoring right now. I
always try to adhere to best practices and testing is one of them.

(system) #7

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