You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add integration tests in the form of either (1) wrapper calls to the SPL command executable (at the "chunked" protocol level, or (2) full end-to-end test in the form of run-anywhere SPL command with an expected output.
Simulate splunk interface
PRO: Better "unittest" like concept; modular.
PRO: Allows for easier automated testing unittest framework and automated testing with Travis.
It may be possible to avoid low-level chunked encoding stuff by using mock.
Test it in Splunk
PRO: A full end-to-end test may catch additional corner cases.
CON: More overhead
CON: Requires a fully running Splunk instance, and authentication to connect via the SDK (REST endpoints)
Alternatively, could be implemented as a dashboard or something like that where all the test run automatically whenever the dashboard is loaded. Seems like this could be painful to troubleshoot, but it would allow the entire test suite to be shipped with the product so that end-users could confirm behavior. (Seems complicated.)
Either way, it should be possible to borrow from the existing run-anywhere commands I put together in the docs.
I'm thinking 1 may be easier.
The text was updated successfully, but these errors were encountered:
Add integration tests in the form of either (1) wrapper calls to the SPL command executable (at the "chunked" protocol level, or (2) full end-to-end test in the form of run-anywhere SPL command with an expected output.
Either way, it should be possible to borrow from the existing run-anywhere commands I put together in the docs.
I'm thinking 1 may be easier.
The text was updated successfully, but these errors were encountered: