-
-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
regression in subtest parsing between 4.2.1 an 4.3 #56
Comments
Happy at least the artefacts are working OK in maven central now. I have a slight memory of the changes related to this issues. In one issue, at least, it was pointed how we were parsing subtests completely incorrectly 😞 Will try to have another look this week and see what it should actually be (probably by using some Perl-fu). Thanks a ton for the detailed bug report @cburroughs ! |
The primarily tool I'm working with now is node-tap, so I found its set of tests useful while puzzling this out: https://github.com/tapjs/tap-parser/tree/master/test/fixtures |
Hmmm, had a quick look this afternoon, fixed javadocs errors while building, then tried writing a simple test, but found that I coudln't get it to produce the desired state... subtests might be utterly broken in the |
As stated in the above referenced issue #57 i believe the commit referenced there, a34d494, is indeed to blame. Updating existing tests always smells, and the linked update looks really strange: a34d494#diff-f5bf7967aaf5cfc38fc1e59eb3540a81 The original test was quite valid IMHO, and i do not see any explanation anywhere why the existing test for issue#17 must have been changed. Will see if i can re-introduce the original test case while keeping the implementation work for the rest of the test suite. |
After reading some more comments and docs, i tend to believe that it is probably the plugin code that needs update. The commit blamed above introduced a breaking change in tap4j that fixed sub-test processing, and this breaking change was not propagated to the plugin. I will have a look if i can do something to fix that over the weekend. |
Very likely. The plugin started as a - rather quick - proof of concept based on some other plug-in structure (TestNG maybe?), and the whole code base needs some re-work. I remember it did things like copying files around, and keeping maps in memory. That is probably affecting some users too. If you have any improvements, feel free to submit PR's. I might have a go at updating it too soon (overseas at a conference until beginning of July) |
I have just opened jenkinsci/tap-plugin#24 that fixes the problematic tests and upgrades the tap4j dependency version to the latest greatest (4.4.2) |
I'm trying to upgrade https://github.com/jenkinsci/tap-plugin to use the latest release of tap4j. When doing some I'm running into several failures with the plugins unit tests.
Specifically:
I believe these are related to a change in how subtests are parsed between 4.2.1 and 4.3. I rigged up one of the plugin tests to print more output and looked at how
TestFlattenTapResult#testStripFirstLevel
behaved. This test takes a string representing TAP output likeparses it using tap4j, and then attempts to "flatten" it. I looked at both what the test is evaluating, and the original test set before trying to flatten.
4.2.1
flattened
original
4.3
flattened
original
4.4.1
flattened
original
I'm not familiar with the details of TAP nor the "flattening" that the plugin does. But it appears that starting in 4.3 tap4j started ignoring everything after the start of the second subtest.
Rough cut of plugin test code:
The text was updated successfully, but these errors were encountered: