[
https://issues.apache.org/jira/browse/DAFFODIL-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168267#comment-17168267
]
Mike Beckerle commented on DAFFODIL-2127:
-----------------------------------------
Verified that this description is right. The online web page is not correct:
>From TDMLRunner.scala
{code:java}
case TwoPassRoundTrip => {
// don't compare first parse pass. Because it may or may not match.
//
// There's really two different kinds of tests here that we're not
distinguishing, which
// are
// (a) those where the infoset is what is expected, but doesn't unparse
to the same
// data as original, which then still reparses to that same infoset.
// (b) those where the infoset isn't what is expected, but unparses to
something which
// then parses to what is expected.
}
case ThreePassRoundTrip => {
//
// Arguably, there are two different kinds of tests here that we've
selected just
// one of:
// (a) the original infoset is NOT a match. The later steady-state
infoset
// differs from this original infoset and matches the expected
// (b) the original infoset is a match, and reflects steady state. Just
the unparse from it
// doesn't match the original input data stream. But reparsing that
data stream produces the same
// infoset which demonstrates steady state.
//
// We can tell these apart, by just remembering whether this infoset
matches or not
// rather than reporting a problem here. If after the reparse we get
the expected
// infoset also, then this was NOT an error, and having the same
infoset indicates
// steady state. If after the reparse we get the expected
// infoset but this one was NOT matching the expected, then we must
unparse again to be sure we
// are at steady state.
//
// Instead we choose to just not check this initial infoset at all, and
always behave
// as if it was NOT a match.
//
// val isFirstParseInfosetMatching =
// try {
// verifyParseResults(processor, firstParseResult,
testInfoset, implString)
// verifyLeftOverData(firstParseResult, lengthLimitInBits,
implString)
// true
// } catch {
// case t: TDMLException =>
// false
// }
// if (isFirstParseInfosetMatching) {
// val msg = ("Expected infoset from first parse of data to
NOT match expected infoset, but it did match." +
// "\nShould this really be a %s
test?").format(roundTrip.propValueName)
// throw TDMLException(msg, implString)
// }
}
{code}
> Site doc of twopass and threepass TDML tests is not correct.
> ------------------------------------------------------------
>
> Key: DAFFODIL-2127
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2127
> Project: Daffodil
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 2.3.0
> Reporter: Mike Beckerle
> Priority: Major
>
>
> This doc is not correct. Incorrect text is highlighted in red.
>
> {{twoPass}}
> _tdml:parserTestCase:_ Parse given data, {color:#d04437}compare to expected
> infoset, expect failure.{color} Unparse infoset, compare to given data,
> expect failure. Parse output data to a second infoset. Compare to first
> infoset, expect success.
> _tdml:unparserTestCase:_ Invalid
> {{threePass}}
> _tdml:parserTestCase:_ Parse given data, compare to expected infoset, expect
> failure. Unparse infoset to first output data, compare to given data, expect
> failure. Parse first output data to second infoset. Compare to expected
> infoset, {color:#d04437}expect failure{color}. Unparse second infoset to
> second output data, compare to first output data, expect success.
>
> In a two pass test, the original infoset is not even compared.
> In a three pass test, the reparsed infoset is expected to match and be the
> steady state infoset.
> Arguably these are not the only possible definitions of what a twoPass test
> or threePass test should be, but they are most consistent with our test cases
> to date, and seem useful for testing going forward.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
