We have some base classes which are providing unit testing support from the core (eg : BaseModuleContextSensitiveTest). We can extend those classes into our modules, and can easily follow the unit tests requirements for the development.
But still, I couldn’t find any support for the Aspect-Oriented programming(AOP) based parent test classes in the Core which can help the developers to write the AOP based unit tests easily. Actually, AOP based unit test classes want some additional methods which can create the testing environment with interceptors and service classes.
So I suggest adding the AOP based base testing class support to the Core ( eg : AOPModuleContextSensitiveTest) which will include those required base methods for the AOP based unit tests.
I get this exact idea from the exti18n module and implemented that into the Location based access control module. Sample implementation for the AOPModuleContextSensitiveTest is here.
I’m not sure I clearly understand what you mean by AOP based unit test classes, are you saying you can’t test AOP advice around your service methods? Otherwise sounds to me like you are looking for the features provided by @Before, @After, BeforeClass, @AfterClass.
As @wyclif hinted, it’s mainly about setting up the advices before, and tearing them down after. As such Spring Test supports testing AOP out of the box.
@wyclif I mentioned about setting up the AOP advice environment with the OpenMRS services to run the test methods. We can’t simply do that with the help of BaseModuleContextSensitiveTest base calls.
@mksd yes, I used that same into the Location Based Access Control module test methods. So I suggest to add those base class required for setting up AOP advice environment into the OpenMRS core along with other test base classes
I know historically, our documentation says registering module AOP via config.xml which I believe is the root cause of why this isn’t currently supported, have you tried registering it via annotations and/or the moduleApplicationContext.xml file? Because I believe it would automatically get picked up by spring and be available in tests.
Otherwise, there is some technical reasons why not only module AOP but a couple of other module features aren’t available in tests. I’ll try to explain, module AOP is registered via the config.xml which isn’t available to be parsed by BaseContextSensitiveTest since it’s packaged inside the omod and not the module’s API jar file, in my opinion there is a bigger issue that needs to be addressed that would in turn care of what you are trying to address while taking care too of other things that are not currently supported by the base test classes.
One option, we would need to refactor the module engine first so that we can split the config.xml file into api and web that way the 2 different files get packaged inside their respective jar files, then they can get loaded from the classpath.
With that said, I personally think our module engine has gotten old and needs to be revisited, there is several things it expects devs to define via the config.xml and today technologies we use have evolved and they can now be loaded dynamically from the classpath e.g servlet API 3+ allows dynamic loading of servlets, filters, listeners etc from the classpath, and as I mentioned earlier I believe you can register AOP outside of the config.xml file making these features testable out of the box.
Yes, I registered with config.xml for the AOP. I never tried with the moduleApplicationContext.xml. This may be the cause of the issues which I faced during the test methods.
Maybe, I haven’t analyzed deeper as you said here. I just explored the ways of testing the methods with AOP which are basically registered with Config.xml. I got an option from exti18n module. So I thought to add those basic classes into the core which can be easily extended by other modules rather than duplicating those classes here and there.
I guess my point is, there is a standard way in spring to wrap AOP advice around any bean method using annotations or xml, and I think devs should use that rather than doing it the OpenMRS way via config.xml which has limitations among them being not easily testable and only works for openmrs services.
? Cc :