1. General Note
- Every deployment related test should be written with Arquillian
- Every test that depends on some external deployment into the environment (for example jdbc driver) should be carefully evaluated to consider possible difference in AS7 env
- Stress tests are not reported in this list because they are out of our unit test suite scope. It easy to keep track of them because all class names of this kind o tests contain the word "Stress"
- InFlow test should be carefully evaluated too.
- Also some integration tests are out of unit tests suite scope, but they are listed and commented here to keep track of them and open a discussion about integration tests.
2. Test List
| Stressed condition | AS6 Implementation (ClassName.methodName) package is always org.jboss.test.jca.test | IronJacamar Implementation (packageName.ClassName.methodName) |
JIRA |
|---|---|---|---|
| verify AdminObject deployment, obj types and properties | AdminObjectUnitTestCase.testAdminObject() | TODO. We only verify atm that annotated AdminObject class is correctly processed from an annotation point of view in org.jboss.jca.deployers.annotations.AnnotationsTestCase. testProcessAdministeredObject. | https://issues.jboss.org/browse/JBJCA-485 |
| Test for connection background validation | BackgroundValidationUnitTestCase | To be evaluated: we are testing our Validation mechanism directly, but this test should be ported to stress Validation framework indirectly at deploy time. IOW we can verify with this test if and when validation should stop the deployment. | |
| stress various condition on CM (changing config and/or using it to get connection and so on) | BaseConnectionManagerUnitTestCase | TODO. In fact we have org/jboss/jca/core/connectionmanager/unit/AbstractConnectionManagerTestCase That is the class with right tests. We have to complete it and moreover to check also TxConnectionManagerTestCase and XATxConnectionManagerTestCase. Finally we have to move and complete also NonTxConnectionManagerTestCase | https://issues.jboss.org/browse/JBJCA-486 https://issues.jboss.org/browse/JBJCA-487 |
| CachedConnectionErrorUnitTestCase | To be analysed. Maybe it don't make sense as is for ironjacamar | ||
| CachedConnectionSessionUnitTestCase | To be analysed. Maybe it don't make sense as is for ironjacamar | ||
| verify cf (datasource) correct serialization/deserialization | ConnectionFactorySerializationUnitTestCase | TODO | |
| verify dependency define in jboss-ra.xml | DependsRARUnitTestCase | Does not make sense for ironjacamar | |
| Check deployment of a -ds | DeploymentUnitTestCase | /ironjacamar-adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2TestCase /ironjacamar-adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2XATestCase
NOTE: here we are just testing that deployment is working, while in old test suite also some properties setting are verified | |
| Test HA connection both Local and XA | HAConnectionFactoryUnitTestCase | Does not make sense since we are not supporting HA connection right now. | |
| test in flow RA using a Message Driven Bean | InflowUnitTestCase | TODO. We need to set up a messaging system in our test suite to do that | |
| test correct behavior of ConnectionPool | InternalManagedConnection PoolStatUnitTestCase | TODO | |
| test that calling .close() 2 times on rs, statement, and connection does not throw Exception | JDBCComplianceUnitTestCase | To be evaluated, it's a jdbc compliance test, not directly related to JCA | |
| test that after -ds redeployment connection are obtainable. | JDBCDriverRedeployUnitTestCase | TODO: extending /ironjacamar-adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2TestCase and /ironjacamar-adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2XATestCase
Note: the old test suite is redeploying driver too. It have to be evaluated in our new environment if it make sense and if AS7 would permit driver hot redeployment | |
| test various jdbc statement method | JDBCStatementTestsConnectionUnitTestCase | It's a JDBC test, not a JCA test. To be evaluated | |
| test Local transaction states | LocalTransactionTidyupUnitTestCase | TODO: byteman to be evaluated. Probably not needed here | |
| test Local transaction commits and rollbacks | LocalWrapperCleanupUnitTestCase | TODO: byteman to be evaluated. Maybe useful here. | |
| test marsha/unmarshal of ManagedConnectionFactory and some deployment injection for it | ManagedDeploymentUnitTestCase.java | TODO: the marshal/unmarshal part. The injection is already covered | |
| Verify multi thread correct behavior for DS and JCA adapter in a Tx context | MultiThreadedTxDsUnitTestCase MultiThreadedTxUnitTestCase | TODO for sure, but we have to postpone this after other unit tests porting/implementation, since we need to understand if the AS6 tests in this classes are enough (probably not) or if we need to stress other condition in a mutithread env. Probably we could use for all (or at least almost) of this test the Tx fake implementation we have. If we need (or decite to) use the real arjuna one we probably would need Byteman here, but it have to be carefully evaluated since we are writing pure JCA tests that should not depend on Tx framework used. The best solution frm a Unit test point of view would be to use our fake implementation for every test, but we need to verify if it is possible. | |
| Verify pooling behaviours< | PoolingUnitTestCase PreFillPoolingUnitTestCase.java | TODO: we have 2 classes that should do that in package org.jboss.jca.core.connectionmanager.unit.pool named PoolingTestCase and PreFillPoolingTestCase but all test methods are empty | |
| Test case for resource adapters with primitive config-property definitions | PrimitiveUnitTestCase.java | ConnectionFactories does not make sense anymore. Moreover we are verifying config-property settings and mainly mandatory ones in parser's test cases | |
| ests of the prepared statement cache | PSCacheUnitTestCase.java | TODO, but Not a pure JCA. It's a JDBC tests we have to evaluate if we are going to provide JDBC tests too. | |
| tests if CachedConnectionManager works with reentrant ejbs | ReentrantUnitTestCase.java | It's a JCA/EJB test. It's more an integration test. It would make sense to have it into AS7, but not ironjacamar standalone because we need an EJB environment to do that. | |
| Tests of remote access to a jdbc datasource. | RemoteDSUnitTestCase.java | It would be implemented as integration test, not as part of our unit test suite. Like stress tests. | |
| Unit test for the RetryableResourceException | RetryableResourceUnitTestCase.java | does not make sense we haven't this exception in ironjacamar impl | |
| RollbackOnlyReleaseConnectionUnitTestCase | RollbackOnlyReleaseConnectionUnitTestCase.java | TODO. Our Tx fake implementation should be enough here | |
| tests scoped rar inside ear | ScopedRARNoJBossAppUnitTestCase.java ScopedRARUnitTestCase.java | Integration tests. Suitable for AS7, ironjacamar standalone does not support ear | |
| Tests of how security context interact with the JCA layer. | SecurityContextUnitTestCase | TODO after security integration | |
| StaleConnectionCheckerUnitTestCase | StaleConnectionCheckerUnitTestCase.java | org/jboss/jca/adapters/jdbc/spi/StaleConnectionCheckerTestCase | |
| StatisticsFormatterUnitTestCase | StatisticsFormatterUnitTestCase.java StatisticsReporterUnitTestCase.java | Does not make sense. It will be covered by RHQ integration tests | |
| Unit test for the TestConnection method | TestConnectionUnitTestCase.java | does not make sense is a jmx sever method | |
| Transaction Active test | TransactionActiveUnitTestCase.java | TODO. AS6' one is based on a jms queue. Maybe it should be redefined in another way. To be evaluated. | |
| Unit test for class TxConnectionManager | Unit test for class TxConnectionManager | TODO. Probably we could use for all (or at least almost) of this test the Tx fake implementation we have. If we need (or decite to) use the real arjuna one we probably would need Byteman here, but it have to be carefully evaluated since we are writing pure JCA tests that should not depend on Tx framework used. The best solution from a Unit test point of view would be to use our fake implementation for every test, but we need to verify if it is possible. | |
| Tests unshared connections | UnsharedConnectionUnitTestCase.java | TODO | |
| Test correct deployment of UserTx | UserTxUnitTestCase.java | Doable extending deployers' tes cases. | |
| Inflow unit tests | WorkManagerUnitTestCase.java TimerUnitTestCase.java TxInflowUnitTestCase.java | TO be evaluated | |
| XADSUnitTestCase.java | XADSUnitTestCase.java | done on H2XATestCase | |
| verify correct thrown of XAException | XAExceptionUnitTestCase.java | TODO | |
| Unit test for class XATxConnectionManager | XATxConnectionManagerUnitTestCase.java | TODO. Probably we could use for all (or at least almost) of this test the Tx fake implementation we have. If we need (or decite to) use the real arjuna one we probably would need Byteman here, but it have to be carefully evaluated since we are writing pure JCA tests that should not depend on Tx framework used. The best solution from a Unit test point of view would be to use our fake implementation for every test, but we need to verify if it is possible. |
Comments