stevedlawrence commented on code in PR #1204:
URL: https://github.com/apache/daffodil/pull/1204#discussion_r1752767257
##########
daffodil-tdml-lib/src/main/scala/org/apache/daffodil/tdml/TDMLRunner.scala:
##########
@@ -634,15 +642,33 @@ abstract class TestCase(testCaseXML: NodeSeq, val parent:
DFDLTestSuite) {
lazy val optExpectedOrInputInfoset = (testCaseXML \
"infoset").headOption.map { node =>
new Infoset(node, this)
}
- lazy val optExpectedErrors: Option[ExpectedErrors] = (testCaseXML \
"errors").headOption.map {
- node => ExpectedErrors(node, this)
+ lazy val optExpectedErrors: Option[Seq[ExpectedErrors]] = {
+ val e = (testCaseXML \ "errors" \\ "error")
Review Comment:
The problem if we didn't support `noWarnings` is it would be a huge effort
to add `<tdml:warnings />` to all tests to ensure warnings are never ignored.
We eventually want get to the point where no tests have unexpected warnings and
your new property is definitely the preferred way to enforce that globally over
`<tdml:warnings />` which can't be added globally.
If we do want consistency with validation, we may want to consider
deprecating `<tdml:validation />` and replacing it with a property similar to
the noWarnings one . Just like with warnings, we probably want to get the the
point where there are no unexpected validation errors, and it's much easier to
enforce that by flipping a default flag than adding `<tdml:validaiton />` to
all the tests. If we do this, I'd suggest it be a separate PR since there's
backwards compatibility issues to consider.
Also, I don't think it's worth the added complexity right now to support
something like `<tdml:errors />` means "some errors exist but I don't care
about the message". That might be useful at some point, but that could also be
a separate PR if we want it. The key thing we really need is the noWarnings
capability.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
