Version 10

    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.