ATE: Support multiple providers per suite & transactions per @Test

[paul.robinson]

Pulling out into a separate discussion from: https://community.jboss.org/message/777483

Problem

Currently you can only have one transaction provider per test suite. This is because the particular provider is found on the classpath, and there can only be one. Also, each @Test method can only span a single Transaction. This has the following issues/implications:

1. Test suites that use two or more types of transactions cannot be supported. For example, this would be a problem for the TXBridge tests that bridge  a JTA transaction to a WS-AT transaction and visa-versa. Here some tests start a JTA transaction and others start a WSAT transaction.
2. Test suites that need to invoke two units of work inside separate transactions can't be supported.

Solution

This was proposed by Aslak in the above discussion:

One option would be to allow multiple @Transactional(manager="") annotations on a Test method, or possible introduce a programmable TransactionManager API as well.

@ArquillianResource TransactionManager tm;

tm.begin("JTA", "manager");
tm.begin("WS-AT", "manager"); ..

Can you explain how having "multiple @Transactional(manager="") annotations on a Test method" helps? I don't think I understand this.

The programmable TM API could be an option to support multiple tests per method. I asume the @Test code would look something like this:

@ArquillianResource TransactionManager tm;

@Test
public void someTest() {

     tm.begin("JTA", "manager");
     //do some work
     tm.commit();

     //Assert something

     tm.begin("JTA", "manager");
     //do some different work
     tm.commit("JTA", "manager");

     //Assert something
}

Positives:

1. Can run many separate transactions in the test.
2. Can decide at run-time how many.
3. Can mix different providers in the same test.
4. Could omit the provider and manager to use the defaults.
5. Assertions can be done between and after transactions.
6. A common API for different transaction types (JTA, WS-AT, etc)

Negatives

1. Removes a lot of the benefits of using the ATE abstractions. What we are left with is a much thinner abstraction layer and and API that is very similar to UserTransaction and it's counterparts.

[aslak]

Can you explain how having "multiple @Transactional(manager="") annotations on a Test method" helps? I don't think I understand this.

Multiple @Transactional annotations would allow for multiple providers to create a @Test scoped transaction. I won't help for the case where you want to control them, but you can auto activate a JTA and a WS-X transaciton within the same scope.

[paul.robinson]

Can you explain how having "multiple @Transactional(manager="") annotations on a Test method" helps? I don't think I understand this.

Multiple @Transactional annotations would allow for multiple providers to create a @Test scoped transaction. I won't help for the case where you want to control them, but you can auto activate a JTA and a WS-X transaciton within the same scope.

Ok, so you are saying that multiple transactions would be begun (one per @Transactional) before the @Test is invoked? I'm not sure I see the use-case for this. Maybe I miss-lead you with my TXBridge example. With the TXBridge tests we only start one transaction (JTA or WS-AT) in the test, but the type of transaction started will differ based on the test.

[aslak]

Ok, so you are saying that multiple transactions would be begun (one per @Transactional) before the @Test is invoked? I'm not sure I see the use-case for this. Maybe I miss-lead you with my TXBridge example. With the TXBridge tests we only start one transaction (JTA or WS-AT) in the test, but the type of transaction started will differ based on the test.

That might have been the case! I tought you wanted multiple transactions from different providers active within a Test method, to.. i donno.. test XA?

But you only want multiple providers within a TestClass. In that case, only one @Transactional annotation would be required. With the added attribute "provider" to @Transactional you could define which which provider to use within the Test scope, JTA or WS. (assuming that a Test scoped transaction would work in this case)