Adapted documentation

modules/test/portal-core-unit-testing/README.asciidoc

@@ -1,12 +1,8 @@
 = portal-unit-testing-junit5
 
-== Status
-
-link:https://ehf-ux-build-trunk.ci.dev.icw.int/jenkins/view/All%20(eHF%20CUI[![Build Status]/job/ehf-cui-ehf-common-ui/badge/icon)](https://ehf-ux-build-trunk.ci.dev.icw.int/jenkins/view/All%20(eHF%20CUI)/job/ehf-cui-ehf-common-ui/)
-
 == What is it?
 
-As part of the migration to Junit 5 we restructured the unit-testing of portal-modules as well. It is about mock-classes, base-classes, test-infrastructure and extensions (Junit 5). This is the starting point for all unit-test in the context of the cui-portal. 
+It is about mock-classes, base-classes, test-infrastructure and extensions (Junit 5). This is the starting point for all unit-test in the context of the cui-portal. 
 
 == Maven Coordinates
 
@@ -22,24 +18,12 @@ As part of the migration to Junit 5 we restructured the unit-testing of portal-m
 
 === Configuration
 
-The handling of configuration is simplified. The @EnablePortalConfiguration bootstraps the configuration-sub-system and adds the necessary producer by using @AddBeanClasses.
-
-Caution: part of the migration is using micro-profile-configuration as a recommended step. Sounds complicated but in essence you change your imports from org.apache.deltaspike.core.api.config.ConfigProperty to org.eclipse.microprofile.config.inject.ConfigProperty. The usage is the same.
-
-[source,java]
-----
-@EnableAutoWeld
-@EnablePortalConfiguration
-class ConfigurationEnabledTest {
-----
-
-If you stick to deltaspike-config you need to add the corresponding producer as well
+The handling of configuration is simplified. The `@EnablePortalConfiguration` bootstraps the configuration-sub-system and adds the necessary producer by using `@AddBeanClasses`.
 
 [source,java]
 ----
 @EnableAutoWeld
 @EnablePortalConfiguration
-@AddBeanClasses({ DefaultConfigPropertyProducer.class })
 class ConfigurationEnabledTest {
 ----
 
@@ -70,11 +54,9 @@ class ConfigurationEnabledTest {
     }
 ----
 
-Caution: de.cuioss.portal.core.test.mocks.configuration.PortalTestConfiguration is the successor of com.icw.ehf.cui.portal.configuration.PortalConfigurationMock that will be deprecated soon.
-
 === Testing in a CDI / Portal / JSF Context
 
-The quickest variant is using @EnablePortalUiEnvironment. This is the typical one-stop annotation for testing UI-related modules in the portal-context.
+The quickest variant is using `@EnablePortalUiEnvironment`. This is the typical one-stop annotation for testing UI-related modules in the portal-context.
 
 [source,java]
 ----
@@ -110,7 +92,7 @@ class EnablePortalUiEnvironmentTest {
 === Testing a page / Backing bean
 
 There is a base class for testing Backing beans in a convenient manner:
-de.cuioss.portal.core.test.tests.AbstractPageBeanTest<T> 
+`de.cuioss.portal.core.test.tests.AbstractPageBeanTest<T>`
 Minimal sample, testing the wiring and the object-contracts:
 
 [source,java]
@@ -125,7 +107,7 @@ class ViewBeanTest extends AbstractPageBeanTest<ViewBean> {
 }
 ----
 
-in case your bean needs an initViewAction to be called prior testing this can be done within #getUnderTest():
+in case your bean needs an `initViewAction` to be called prior testing this can be done within `#getUnderTest()`:
 
 [source,java]
 ----
@@ -144,7 +126,7 @@ class ViewBeanTest extends AbstractPageBeanTest<ViewBean> {
 }
 ----
 
-Automatic bean-testing can be introduced by annotating with @VerifyBeanProperty. The further configuration is defined within ValueObjectTest
+Automatic bean-testing can be introduced by annotating with `@VerifyBeanProperty`. The further configuration is defined within ValueObjectTest
 
 [source,java]
 ----
@@ -159,13 +141,13 @@ class ViewBeanTest extends AbstractPageBeanTest<ViewBean> {
 }
 ----
 
-verifyObjectContracts(): Verifies the contract of Object.equals(Object), Object.hashCode(), Object.toString() and Serializable by serializing / deserializing the object. 
+`verifyObjectContracts()`: Verifies the contract of `Object.equals(Object)`, `Object.hashCode()`, `Object.toString()` and `Serializable` by serializing / deserializing the object. 
 
 _Caution_: it will check less detailed compared to previous variants. If you want a full blown test use ValueObjectTest directly. If you want to adapt the test you must override it. Previous annotation will not work.
 
 === Testing a ResourceBundle-Locator
 
-This tests the initial structure, the provided path and an actual message to be resolved. In order to work the module needs a test / runtime dependency on com.icw.ehf.cui.portal.cdi:cdi-portal-core-impl
+This tests the initial structure, the provided path and an actual message to be resolved. In order to work the module needs a test / runtime dependency on `de.cuioss.portal.ui:portal-ui-runtime`
 
 [source,java]
 ----
@@ -194,7 +176,7 @@ class RuntimeBundleNamesTest implements ShouldBeNotNull<RuntimeBundleNames> {
 
 === Testing with PortalMessageProducer
 
-If you experience: `Could not load bean of type com.icw.ehf.cui.core.api.application.message.MessageProducer and name #{messageProducer}`
+If you experience: `Could not load bean of type MessageProducer and name #{messageProducer}`
 setup your test class as following:
 
 [source,java]
@@ -215,15 +197,15 @@ class MyTestClass extends AbstractPageBeanTest|AbstractValidatorTest|... {
 
 === Module Consistency Test
 
-A consistent module must be deployable within a CDI-Context. It must define all dependencies. This is checked by de.cuioss.portal.core.test.tests.BaseModuleConsistencyTest the successor of de.icw.cui.test.cdi.BaseCdiContextTest that will be deprecated soon.
+A consistent module must be deployable within a CDI-Context. It must define all dependencies. This is checked by `de.cuioss.portal.core.test.tests.BaseModuleConsistencyTest`.
 
 [source,java]
 ----
 class ModuleConsistencyTest extends BaseModuleConsistencyTest {
 }
 ----
 
-The test actually starts a Weld-Container and looks up the Bean-Manager. In addition it checks for the file META-INF/beans.xml being present. 
+The test actually starts a Weld-Container and looks up the Bean-Manager. In addition it checks for the file `META-INF/beans.xml` being present. 
 
 In case you want to add beans or modify the dev-mode you just need to implement the callback method:
 
@@ -250,7 +232,7 @@ The corresponding producer-types are defined at https://github.com/cuioss/cui-js
 
 === Assembly Consistency Test
 
-A consistent assembly must be deployable within a CDI-Context. It must define all dependencies. This is checked by de.cuioss.portal.core.test.tests.BaseAssemblyConsistencyTest.
+A consistent assembly must be deployable within a CDI-Context. It must define all dependencies. This is checked by `de.cuioss.portal.core.test.tests.BaseAssemblyConsistencyTest`.
 
 [source,java]
 ----
@@ -262,7 +244,7 @@ The test actually starts a Weld-Container and looks up the Bean-Manager. In addi
 
 === Handling AuthenticatedUserInfo
 
-If you need an AuthenticatedUserInfo, add de.cuioss.portal.core.test.mocks.authentication.PortalTestUserProducer, the successor of de.icw.portal.core.test.mocks.PortalUserProducerMock that will be deprecated soon.
+If you need an `AuthenticatedUserInfo`, add `de.cuioss.portal.core.test.mocks.authentication.PortalTestUserProducer`.
 
 [source,java]
 ----
@@ -288,12 +270,12 @@ class PortalTestUserProducerTest {
 
 === Testing a configuration Module
 
-Extend de.cuioss.portal.core.test.tests.configuration.AbstractConfigurationKeyVerifierTest, the successor of com.icw.ehf.cui.portal.configuration.AbstractConfigurationKeyVerifierTest that will be deprecated soon.
+Extend `de.cuioss.portal.core.test.tests.configuration.AbstractConfigurationKeyVerifierTest`.
 The actual documentation can be found at class level
 
 === Testing NavigationMenuItems
 
-The base class is de.cuioss.portal.core.test.tests.navigation.PortalNavigationMenuItemsTest replacing de.icw.portal.core.test.navigation.PortalNavigationMenuItemPackageTest that will be deprecated soon
+The base class is `de.cuioss.portal.core.test.tests.navigation.PortalNavigationMenuItemsTest`
 
 [source,java]
 ----
@@ -365,7 +347,7 @@ class MockWebServerExtensionTest implements MockWebServerHolder {
 
 ==== Dispatching Requests
 
-If you want to reuse the request dispatching of the server you can provide a concrete implementation for de.cuioss.portal.core.test.junit5.mockwebserver.MockWebServerHolder.getDispatcher()
+If you want to reuse the request dispatching of the server you can provide a concrete implementation for `de.cuioss.portal.core.test.junit5.mockwebserver.MockWebServerHolder.getDispatcher()`
 
 [source,java]
 ----
@@ -401,7 +383,7 @@ class ValueSetClientImplFhirTest implements MockWebServerHolder {
 
 ==== de.cuioss.portal.core.test.junit5.mockwebserver.dispatcher.ModuleDispatcherElement
 
-The idea of an ModuleDispatcherElement is the reuse of answers in the context of EnableMockWebServer. In essence calls to MockWebServerHolder.getDispatcher() can be replaced with this structure.The general idea is to return an Optional MockResponse if the concrete handle can answer the call, Optional.empty() otherwise.
+The idea of an `ModuleDispatcherElement` is the reuse of answers in the context of `EnableMockWebServer`. In essence calls to `MockWebServerHolder.getDispatcher()` can be replaced with this structure.The general idea is to return an `Optional` `MockResponse` if the concrete handle can answer the call, `Optional.empty()` otherwise.
 
 Dispatcher for a jwks endpoint 
 
@@ -500,7 +482,7 @@ class TokenParserProducerTest implements ShouldBeNotNull<TokenParserProducer>, M
 
 === Testing InstallationPaths
 
-On some rare cases you need to access the de.cuioss.portal.configuration.installationpaths.InstallationPaths in a mock variant. This can be done by using:
+On some rare cases you need to access the `de.cuioss.portal.configuration.installationpaths.InstallationPaths` in a mock variant. This can be done by using:
 
 [source,java]
 ----