TestSuite - mapping test cases for AS6 and IronJacamar

1. General Note

 

  1. Every deployment related test should be written with Arquillian
  2. 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
  3. 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"
  4. InFlow test should be carefully evaluated too.
  5. 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 propertiesAdminObjectUnitTestCase.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 validationBackgroundValidationUnitTestCase

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

https://issues.jboss.org/browse/JBJCA-488

https://issues.jboss.org/browse/JBJCA-489


CachedConnectionErrorUnitTestCaseTo be analysed. Maybe it don't make sense as is for ironjacamar

CachedConnectionSessionUnitTestCaseTo be analysed. Maybe it don't make sense as is for ironjacamar
verify cf (datasource) correct serialization/deserializationConnectionFactorySerializationUnitTestCaseTODO
verify dependency define in jboss-ra.xmlDependsRARUnitTestCaseDoes not make sense for ironjacamar
Check deployment of a -dsDeploymentUnitTestCase

/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 XAHAConnectionFactoryUnitTestCaseDoes not make sense since we are not supporting HA connection right now.
test in flow RA using a Message Driven BeanInflowUnitTestCaseTODO. 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 ExceptionJDBCComplianceUnitTestCaseTo be evaluated, it's a jdbc compliance test, not directly related to JCA
test that after -ds redeployment connection are obtainable.JDBCDriverRedeployUnitTestCaseTODO: 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 methodJDBCStatementTestsConnectionUnitTestCaseIt's a JDBC test, not a JCA test. To be evaluated
test Local transaction statesLocalTransactionTidyupUnitTestCaseTODO: byteman to be evaluated. Probably not needed here
test Local transaction commits and rollbacksLocalWrapperCleanupUnitTestCaseTODO: byteman to be evaluated. Maybe useful here.
test marsha/unmarshal of ManagedConnectionFactory and some deployment injection for itManagedDeploymentUnitTestCase.javaTODO: 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.java
PreFillPoolingUnitTestCase.java

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 definitionsPrimitiveUnitTestCase.javaConnectionFactories 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 cachePSCacheUnitTestCase.javaTODO, 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 ejbsReentrantUnitTestCase.javaIt'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.javaIt would be implemented as integration test, not as part of our unit test suite. Like stress tests.
Unit test for the RetryableResourceExceptionRetryableResourceUnitTestCase.javadoes not make sense we haven't this exception in ironjacamar impl
RollbackOnlyReleaseConnectionUnitTestCaseRollbackOnlyReleaseConnectionUnitTestCase.javaTODO. 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.SecurityContextUnitTestCaseTODO after security integration
StaleConnectionCheckerUnitTestCaseStaleConnectionCheckerUnitTestCase.javaorg/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 methodTestConnectionUnitTestCase.javadoes not make sense is a jmx sever method
Transaction Active testTransactionActiveUnitTestCase.javaTODO. AS6' one is based on a jms queue. Maybe it should be redefined in another way. To be evaluated.
Unit test for class TxConnectionManagerUnit test for class TxConnectionManagerTODO. 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 connectionsUnsharedConnectionUnitTestCase.javaTODO
Test correct deployment of UserTxUserTxUnitTestCase.javaDoable extending deployers' tes cases.
Inflow unit tests

WorkManagerUnitTestCase.java

TimerUnitTestCase.java

TxInflowUnitTestCase.java

TO be evaluated
XADSUnitTestCase.javaXADSUnitTestCase.javadone on H2XATestCase
verify correct thrown of XAExceptionXAExceptionUnitTestCase.javaTODO
Unit test for class XATxConnectionManagerXATxConnectionManagerUnitTestCase.javaTODO. 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.