PIT with AspectJ (Spring)

[Eduardo Simioni]

Hi,

I have an interesting scenario. I use Spring with real (AspectJ) aspects.
This means that for every method that has a @Transactional annotation some aspects are injected in the bytecode.
When I run PIT I have lots of similar mutations that are not killed, for example:

removed call to org/springframework/transaction/aspectj/AbstractTransactionAspect::ajc$afterReturning$org_springframework_transaction_aspectj_AbstractTransactionAspect$3$2a73e96c : SURVIVED
removed call to org/springframework/transaction/aspectj/AbstractTransactionAspect::ajc$afterThrowing$org_springframework_transaction_aspectj_AbstractTransactionAspect$2$2a73e96c : SURVIVED
removed call to org/springframework/transaction/aspectj/AbstractTransactionAspect::ajc$before$org_springframework_transaction_aspectj_AbstractTransactionAspect$1$2a73e96c : SURVIVED
removed call to org/springframework/transaction/aspectj/AbstractTransactionAspect::ajc$after$org_springframework_transaction_aspectj_AbstractTransactionAspect$4$2a73e96c : SURVIVED

The reason why they are not killed is quite obvious, for example the "afterThrowing" aspect will rollback the transaction and raise the exception to my code, but realistically the responsibility of handling this scenario is of the aspect itself, not my code, so I don't write a test case for each @Transactional method mimicking an exception. The "before" and "after" aspects also will not do anything in unit tests since the tests themselves are the boundaries of the transactions.

In many classes in my project these are the only not killed mutations, making it very laborious to find real mutation problems.

My question is: Is there a way to avoid these specific mutations? I don't want to remove the mutator altogether, nor ignore all aspects, just for this specific aspect.


Thanks,

Eduardo Simioni.

[Henry Coles]

Hi Eduardo,

The avoidCallsTo option might solve your problem - this gives PIT a list of classes/packages that it should avoid mutating calls too. If a line of code contains a call to one a method in one of these classes, no mutations will be made to that line. This was introduced to reduce the noise from logging concerns within the code, but might help here.

Try adding org.springframework.transaction.aspectj.AbstractTransactionAspect to the avoidCallsTo list and see if it helps.


Henry

[Eduardo Simioni]

Thanks Henry,

It worked at first, but I have another problem.
All my tests are passing when running without PIT, but with PIT many times it doesn't start the mutations reporting that the test suite is not green.
I use H2 database and when running from PIT some tests fail reporting that a table doesn't exist. It appears to me that it is a concurrency issue regarding the in-memory database and PIT. It doesn't happen all the time but almost, I could runt PIT only once today in 30 or more tries.
I run it with Maven and single thread (default).

Do you have any recommendation regarding this problem?

Thanks,

Eduardo Simioni.

[henry]

Hi Eduardo,

It's good to hear that PIT works with AspectJ.

I'm guessing this is either a test ordering issue or a timing issue i.e. your tests might not be 100% repeatable (as in http://pragprog.com/magazines/2012-01/unit-tests-are-first ).

I've never actually checked that PIT runs tests in a fully repeatable and deterministic order during the coverage stage. It certainly ought to be guaranteeing this (and I think it probably does), but I'll add some tests in to check.

How is the H2 schema setup for your tests? In a @Before method, in a @BeforeClass, in some other fashion? Could you post a reduced example test?

Thanks

Henry

[Eduardo Simioni]

Hi Henry,

I solved the problem with H2 database by adding the DB_CLOSE_DELAY option to the connection URL: jdbc:h2:mem:myapp_test;DB_CLOSE_DELAY=10
I was able to run PIT 5 times in a row now without problems.

I'll add more details because it might be helpful for other similar problems:
My test suite is fully deterministic, I can run it 1000 times with Maven or my IDE and it will never fail, no matter if I run the full suite or any subset. It would only fail with PIT, always with the same missing table error.
For my test suite, the database is created only once at the beginning, together with the Spring Context/Session Factory by setting the property "hibernate.hbm2ddl.auto" to "create", and it is never closed programmatically.
From the H2 website: "Usually, a database is closed when the last connection to it is closed" (when the close delay option is not used).

I have another issue now, I guess I'm pushing PIT to its limits :)
I'll do a bit of research and if needed, create a different topic for it.

Cheers,

Eduardo.