Testcaseset (have a testcase in one hash) #21
Conversation
in preparation for the additon of the extended testcase feature in the config files.
|
At a later point I would consider to deprecate the fields |
|
I would LOVE to see this implemented/merged. Sometimes, input lines are almost identical, but the result is very different. On other cases, I have a lot of different test lines in one test file and it's really hard to manage. |
There was a problem hiding this comment.
This makes total sense. I just wonder how we keep support for testcases involving multiple lines. While the multiline filter has been deprecated there are other filters like aggregate and collate that rely on multiple input lines and that should be testable. I suppose we could either
- make TestCaseSet support multiple input lines and expected events or
- keep the legacy
inputandexpectedfields around for multiline needs.
The former would allow us to (eventually) remove input and expected but would also add an extra layer of arrays just to support an unusual use case.
testcase/testcase_test.go
Outdated
| @@ -368,10 +368,10 @@ func TestMarshalToFile(t *testing.T) { | |||
| } | |||
| } | |||
|
|
|||
| func marshalTestCase(t *testing.T, tc *TestCase) string { | |||
| resultBuf, err := json.MarshalIndent(tc, "", " ") | |||
| func marshalTestCase(t *testing.T, tcs *TestCaseSet) string { | |||
There was a problem hiding this comment.
Rename to marshalTestCaseSet()?
The test case file now supports an additional section called `testcases`, which consists of an input line and the expected event, after processed by Logstash. This allows for clean test case files, as the actual input is just next to the expected output, which makes working with the test case files much easier.
|
I just updated the PR based on your feedback and merged master to resolve the merge conflicts. Regarding the testcases involving multiple lines I think in the long run I personally would prefer to make TestCaseSet to support multiple lines, and to deprecate the legacy @magnusbaeck if you agree, I offer to update/extend the PR. |
Sounds good. Let's add support for multiline TestCaseSet now and aim for deprecation of the legacy options in a 2.0 release.
Yes, please! |
|
@magnusbaeck I had an other look at the filter plugins you mentioned in #21 (review) and also looked at some other special cases.
|
|
Excellent! We can figure out the metrics filter later on. I'll look through all patches this weekend. |
|
Branch rebased and merged to master. |
Added testcases section to the test case file
The test case file now supports an additional section called
testcases, which consists of an input line and the expected event, after processed by Logstash.This allows for clean test case files, as the actual input is just next to the expected output, which makes working with the test case files much easier.
Renamed TestCase to TestCaseSet
Renamed TestCase to TestCaseSet in preparation for the additon of the extended testcase feature in the config files. (separate commit).
Future improvements
The new
testcasesstruct could be further extended, for example with the following fields:json_lines: as an alternative way to provide the input, which would remove the need for the escaping of json input in theinputfield.ignore_fields: fields, that should be ignored just for the actual test case, additionally to the globally defined ignored fields.description: short description field for the test case, which would allow to describe, why the test case was added, e.g. with reference to ticket describing the bug/issue. This description could be printed while running the tests instead of (or additional to) the current outout:Comparing message <n> of <filename>...