[bv-dev] TCK Beta3 (was: "Constraint given several times")

[Gunnar Morling]

Hi,

As discussed with Hardy the test is updated now to expect two violations.

Btw. we released Beta3 of the TCK yesterday [1] (including this change). So
for those of you working on implementations of the spec it's the perfect
time to checkout tests new tests and let us know if any of the tests are
problematic etc.

We've basically assertions for all new functionality added in 1.1, with
~83% of these assertions already covered by tests (as measured with the
coverage tool [2]).

Speaking about tooling, the audit.xml file containing all the assertions is
generated now from the actual spec text using an XSL transformation. That
way wording and structure of the TCK match 100% with the spec, but this
change caused some re-arrangement of existing tests. This should have no
influence on implementations, the actual tests are the same as before.

--Gunnar

[1]
http://in.relation.to/Bloggers/InUnisonReleaseOfBeanValidationTCK110Beta3AndHibernateValidator500Beta1

[2]
http://docs.jboss.org/hibernate/beanvalidation/tck/1.1/reference/html_single/#d0e438


2013/2/6 Hardy Ferentschik <hardy at hibernate.org>

> Hi,
>
> >From a runtime perspective I can see how a single constraint violation
> can make sense as well.
> We have a single instance of Woman validating the Default group. I can see
> how only one violation
> makes sense. The problem is the metadata. It would not be defined which
> constraint meta data you
> would get when inspecting the constraint violation. The one from Citizen
> or the one from Person.
>
> I am wondering whether the group parameter contributes to constraint
> equality or whether it should be
> excluded.
>
> If there are no other objections I am ok with updating this behaviour and
> test, but I can see the merit in
> the current behaviour as well.
>
> --Hardy
>
>
> On 5 Jan 2013, at 4:42 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> > Hi all,
> >
> > While working on a bug in the RI [1], I came across a TCK test which
> made me curious: ValidationRequirementTest#testClassLevelConstraints() [2].
> The test is based on the following types:
> >
> >     @SecurityCheck(groups = { Default.class, TightSecurity.class })
> >     public interface Citizen { ... }
> >
> >     @SecurityCheck(groups = Default.class)
> >     public abstract class Person implements Citizen { ... }
> >
> >     public class Woman extends Person { ... }
> >
> > The test validates an instance of Woman which violates the
> @SecurityCheck constraint(s), but expects only one violation of the type
> @SecurityCheck.
> >
> > Since the constraint is given twice in the hierarchy (and with different
> member values), I'd have expected two violations here. I spoke to Emmanuel
> and we agree that the test seems wrong.
> >
> > The RI passes that test due to the bug mentioned above, but it'd be
> interesting to know how this is handled in the Apache implementation and
> why it's passing there.
> >
> > If no one objects, I'll adapt the TCK test to expect two @SecurityCheck
> violations.
> >
> > --Gunnar
> >
> > [1] https://hibernate.onjira.com/browse/HV-665
> > [2]
> https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/src/main/java/org/hibernate/beanvalidation/tck/tests/constraints/application/ValidationRequirementTest.java#L60
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20130207/fa486312/attachment.html