JUnit Runner API

[bbq2100]

Features:

• More convenient option for using DI in the test: the User should be able to use directly @Inject in the corresponding Unit Tests e.g:

  @RunWith(BeanTestingRunner.class) class ServiceTest{ @Inject Service service; }

• The possibility to run the tests in a given transaction by the Runner. (as its already provided with the AbstractBeanProvider) The user just provide as normal a configuration for the persistence unit (persistence.xml).

• A facility for the user to provide additional classes which may be not found by the underlying Weld Se Container e.g:

  @ClassesWhichEverWereNotFound(Service.class, Service1.class)

• The user should also be able to provide CDI Alternatives. That means the user intentionally creates CDI Alternatives for the Unit Tests and provide these implementations to the underlying Weld Se Container.

[bbq2100]

Dropped the following feature :

• A option for the user to provide the session scope for the beans e.g: @ScopeForTest(ReuestScoped.class) @ScopeForTest(SessionScoped.class)

There is no need for it since there are only two scopes available in the JUnit test environment: Request and ApplicationScoped. So the user should autom. be able to choose accordingly the desired scope.

[bbq2100]

Regarding the feature of providing additional classes: this feature also has the following positive effect: there is no need for the user to provide a beans.xml in the test folder ( test/ressources. ) This implies that all classes, interceptor or extensions which are needed for running the test should be provided via this feature.

[bbq2100]

After working with arquillian and the ShrinkWrap API, maybe BeanTesting should also provide such a feature regarding the creation of needed deployment descriptors (Convention over configuration): beans.xml, persistence.xml etc.a declarative way of setting deployment descriptors

[agori]

What about this?

@RunWith(BeanTest.class)
public class ServiceTest {

   @Inject MyService service;
   @Inject UserTransaction tx

    @Test @AutoRollback
    public void test() {
        myService.saveUser(new User("lagoria"));
    }

    @Test @ManualTransaction
    public void test() {
        tx.begin();
        myService.saveUser(new User("lagoria"));
        tx.rollback();

    }

}

[bbq2100]

So you´re basically proposing a transaction control mechanism ('AutoRollback' and 'ManualTransaction') inside BeanTests? Further your code snippet contains ‘@Inject UserTransaction‘. Currently this is not possible...I just tried it out. So 'BeanTestingRunner' should also provide the current 'UserTransaction'.

[carlosbarragan]

I'm not sure that providing a facility to tests transactions is a good idea. IMHO if you need to test transaction behavior, you should refactor your code. BeanTest tries to hide the whole transaction propagation, so the user can concentrate on testing business logic inside an application module.

I also think this feature could be complicated to implement because we have to somehow expose the local transaction through UserTransaction. On the other hand, some time in the future we will probably have to provide access to the UserTransaction inside an EJB.

@qabbasi the injection of UserTransaction doesn't work because there is no Producer for it.

[agori]

@carlosbarragan its purpose is not to test transaction behavior but to give the possibility of rolling back the current transaction so that the database is not modified.

[carlosbarragan]

@agori why do you want to avoid DB updates? Every test method should start with a clean DB state.

[agori]

@carlosbarragan I am not fostering a rollback after each test, but it's a common technique used by a lot of developers. IMHO it would be nice to leave the freedom.

[carlosbarragan]

@agori IMHO rolling back the transaction is not a good practice. Even if you called the persist or merge method and rollback the transaction, you can still have DB-errors undiscovered because of the underlying database constraints.

Having a clean DB state at every test method is the best practice. Yes, the developers should have the freedom to choose but a framework should lead into using best practices.