guhilling / cdi-test Goto Github PK

Is your feature request related to a problem? Please describe.
Handling proper log output and proper levels is still awful with idk logging.

Describe the solution you'd like
Use slf4j as log "frontend" and probably log4j2 as the default backend. backend can be replaced if necessary. Everybody is using slf4j-api anyway no this shouldn't lead to any problems.

Describe alternatives you've considered
Keep using idk logging.

https://github.blog/changelog/2023-01-18-code-scanning-codeql-action-v1-is-now-deprecated/

Is your feature request related to a problem? Please describe.
Some days ago I noticed cdi-test and today was the day I wanted to use it. After setting up my project and my first test I executed it I got the following error messages:

cannot access de.hilling.junit.cdi.CdiTestJunitExtension bad class file: ...\de\hilling\junit\cdi\cdi-test-core\3.2.1\cdi-test-core-3.2.1.jar(de/hilling/junit/cdi/CdiTestJunitExtension.class) class file has wrong version 55.0, should be 52.0

The error claims that the Extension class is written in Java 11 and therefore is not compatible to Java 8 (which I have to use at work). I then checked the documentation twice, but didn't find a notice about the required version and that it is not compatible to the (minimum) Java version required by JUnit Jupiter.

Describe the solution you'd like
Solution I like? Make it compatible to Java 8 ;)

Describe alternatives you've considered
A clear and concise notice / warning that Java 11 is required.

Is your feature request related to a problem? Please describe.
Package-Info
Doc all classes

Is your feature request related to a problem? Please describe.
The only supported cdi feature for test cases is field injection. This should be verified during test setup.
Also some other things like test class visibility etc. could be checked.
Right now things might "silently" go wrong although throwing an exception or at least issuing a warning should be not problem.

Describe the solution you'd like
Create a verifier for all of the test classes.

Describe alternatives you've considered
None.

Additional context
None

• JakartaEE 9 not supported
• Stalled development?

Currently qualifiers aren't considered when injecting fields on the test case. To support e.g. multiple EntityManagers this must be possible.

Hello.

I'm trying to replace cdi-unit by cdi-test. I already managed to make it work for several cases, however I hit in a situation where I need several mocks of the same type on the same test.
Due to a validation in cdi-test we can't inject mocks with the same type.

I would like that we use another attribute as a discriminator, allowing several mocks of the same type to be injected. Maybe mocks with a given name, could be injected with @Named or a qualifier with the same name as the mock.

No workaround came to my mind.

The code where it is blocking the injection:

    @Override
    public synchronized void onMockCreated(Object mock, MockCreationSettings settings) {
        final Class<?> typeToMock = settings.getTypeToMock();
        final Map<Class<?>, Object> mocks = currentMockSet();
        if (mocks.containsKey(typeToMock)) {
            throw new CdiTestException("mock " + typeToMock + " already in set");
        }
        try {
            mocks.put(typeToMock, mock);
        } catch (UnsupportedOperationException uoe) {
            // IGNORE
        }
    }

Describe the bug

The dependency information inside the documentation uses version 3.2.2 of cdi-test, but this version was never released according to GitHub releases and Maven central.

To Reproduce
Read dependency information in the docs.

Expected behavior
The dependency information / documentation is in line with the current release or the version is left out and a reminder like "Don't forget to add a version information" is added.

Additional context
Not relevant.

Is your feature request related to a problem? Please describe.
I want to be able to test @transactional cdi components.

Describe the solution you'd like
Use Weld JTA and JPA integration with Narayana.

Describe alternatives you've considered
Use Atomikos instead of Narayana? But the documentation and samples for Narayana are sufficient now and it's used in Wildly anyway.

Additional context
The "old" solution (cdi-jee) will remain as-is.

#341 should be solved first to simplify matters

I'd like to use Kotlin and the MockK library to generate mocks for cdi-test, but cdi-test doesn't seem to pick up de annotated mocks.
I'd like some hints as to how I can extend cdi-test to support MockK mocks.
Mockito seeems to work as described, but I like the Kotlin DSL of MockK better and would like to use that instead.
Any hints would be appreciated, I'll start taking a look myself though.

Much simpler and cleaner setup as it used to be in 4.x.

This will also simplify things like proper jta support a lot.

Describe the bug
A second instance is created for injection.
This might lead to problems if state is maintained in the constructor of the test class.

To Reproduce
Run any test.

Expected behavior
create only one instance. Maybe use a generated class for injection.

Describe the bug
Producers with InjectionPoint not supported for TestCase-Injections.

To Reproduce
Steps to reproduce the behavior:
Run InjectionTest (new version).

Expected behavior
Should be possible to inject.

Additional context

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context about the feature request here.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context about the feature request here.

Is your feature request related to a problem? Please describe.

• Tutorial
• FAQ
• Pitfalls
• Structure

Describe the bug
Whenever I try to run SimpleTest.java as shown here

https://github.com/guhilling/cdi-test

I'm getting the exception below.

To Reproduce
Steps to reproduce the behavior:

1. Run Test
2. See error

Expected behavior
Test should run.

Additional context
Gradle project (v7.4)
JDK 17
Windows 10

Exception
org.jboss.weld.exceptions.IllegalArgumentException: WELD-001456: Argument bean must not be null at org.jboss.weld.util.Preconditions.checkArgumentNotNull(Preconditions.java:40) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:708) at org.jboss.weld.util.ForwardingBeanManager.getReference(ForwardingBeanManager.java:64) at org.jboss.weld.bean.builtin.BeanManagerProxy.getReference(BeanManagerProxy.java:87) at de.hilling.junit.cdi.ContextControlWrapper.getContextualReference(ContextControlWrapper.java:58) at de.hilling.junit.cdi.CdiTestJunitExtension.beforeEach(CdiTestJunitExtension.java:83) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeBeforeEachCallbacks$2(TestMethodTestDescriptor.java:163) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeBeforeMethodsOrCallbacksUntilExceptionOccurs$6(TestMethodTestDescriptor.java:199) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeBeforeMethodsOrCallbacksUntilExceptionOccurs(TestMethodTestDescriptor.java:199) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeBeforeEachCallbacks(TestMethodTestDescriptor.java:162) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:129) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141) at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138) at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141) at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138) at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141) at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138) at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95) at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:35) at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57) at org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:54) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:107) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52) at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:114) at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:95) at org.junit.platform.launcher.core.DefaultLauncherSession$DelegatingLauncher.execute(DefaultLauncherSession.java:91) at org.junit.platform.launcher.core.SessionPerRequestLauncher.execute(SessionPerRequestLauncher.java:60) at org.eclipse.jdt.internal.junit5.runner.JUnit5TestReference.run(JUnit5TestReference.java:98) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:40) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:529) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:756) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:452) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:210)

Describe the bug
To work properly, cdi-test-microprofile needs to operate on normal scoped beans.

To Reproduce

1. Run Test DependentScopedComponentTest.
2. testCaseAnnotatedValue returns the same result as the first method.

Expected behavior
Value should be "Hello Test"