Test framework extensions (JUnit 4, JUnit 5, Spock) for unit testing CDI components with a real Weld container.
Weld Testing Extensions is a set of test framework extensions for JUnit 4, JUnit 5, and Spock that enhance the testing of CDI components using the Weld container. It allows developers to run unit tests with a real CDI container, providing full bean capabilities like injection, interception, and events without requiring mocks or simulations. The extensions support Weld 5 and later, including Weld 6.0 with the Jakarta namespace.
Java developers working with CDI (Contexts and Dependency Injection) who need to write unit or component tests for their beans, particularly those using the Weld implementation in Java SE or Java EE environments.
Developers choose Weld Testing Extensions because it eliminates the complexity of simulating CDI behavior in tests by providing a real container, reducing reliance on mocking frameworks and ensuring tests reflect actual runtime conditions. Its support for multiple testing frameworks (JUnit 4, JUnit 5, Spock) and easy integration with mocks offers flexibility and simplicity in testing CDI components.
Set of test framework extensions (JUnit 4, JUnit 5, Spock) to enhance the testing of CDI components via Weld. Supports Weld 5.
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Starts an actual Weld CDI container for each test, enabling full bean capabilities like injection, interception, and events without mocking, as per the README's emphasis on eliminating complex simulations.
Provides extensions for JUnit 4, JUnit 5, and Spock, allowing integration with popular testing frameworks, which is clearly listed in the README for flexible adoption.
Allows @Inject directly into test classes, simplifying test setup and reducing boilerplate code, as highlighted in the README's feature list.
Enables customization of beans, extensions, and interceptors within the container, offering tailored testing scenarios as described in the README.
Initiating a real CDI container before each test run can add significant time to test execution, which might hinder performance for large or frequent test suites.
Tightly coupled with the Weld CDI implementation, creating vendor lock-in and limiting use for projects that might switch to other CDI providers or DI frameworks.
While minimal for basic use, advanced customizations of beans and extensions require additional setup, which can be intricate and time-consuming, as implied by the need for separate README files per framework.