Skip to content
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

Inspect tests disabled directly in code and change them as needed #446

Closed
manovotn opened this issue Mar 22, 2023 · 1 comment · Fixed by #482
Closed

Inspect tests disabled directly in code and change them as needed #446

manovotn opened this issue Mar 22, 2023 · 1 comment · Fixed by #482
Assignees

Comments

@manovotn
Copy link
Contributor

The issue was brought up via email, see this thread.

IIRC, according to TCK doc, all intentionally disabled tests should be mentioned in tck-tests.xml.
However, we currently have two tests that are disabled directly in code and not mentioned in the XML, those are:

We need to take a look at them and determine how to treat them (i.e. if they still need to be disabled and is so then do that via XML file).

@manovotn manovotn self-assigned this Oct 3, 2023
@manovotn
Copy link
Contributor Author

manovotn commented Oct 3, 2023

https://github.com/jakartaee/cdi-tck/blob/master/web/src/main/java/org/jboss/cdi/tck/tests/definition/bean/types/enterprise/illegal/BeanTypesWithIllegalTypeTest.java#L62

Legacy JIRA link - https://issues.redhat.com/browse/CDITCK-575

The assertion linked to this test is marked as not testable and due to the limitation on the type of resource in web.xml the original format of this test was invalid.
I don't believe we can test this - the set of valid values for resource is limited and it seems that its types are all legal bean types.
We could probably just delete this test and associated unused classes.

https://github.com/jakartaee/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/full/definition/bean/custom/CustomBeanImplementationTest.java#L143

Legacy JIRA link - https://issues.redhat.com/browse/CDITCK-579

The assumption made by this test seems correct but there is no guarantee about when that happens.
However, if we make sure the test actually creates an instance of the bean (so that injection into contextual reference triggers), it should be safe to assert it. This is something we should check up on with OWB impl which originally filed the TCK JIRA.

I'll send a PR with suggested changes shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant