I have a large grails project split into several 'in place' plugins to keep things nice and modular. One of my plugins, called 'core services', contains all my domain classes, and also some nice set up work in an abstract test class (adding mock domain instances, etc) that is shared by a number of unit tests.
This is all great for unit tests that also live in the plugin, but I'd like to use that abstract test class to set up mock data in other grails projects' tests that uses that plugin. It doesn't seem that plugins' test classes are included on the classpath when running tests. Is there a way I can tell Grails to include them?:
//this abstract test class is in the core service plugin's test directory. My IDE has no problem with this import
import com.myproject.coreservices.service.AbstractGiftInstanceRelatedUnitTest
//this test class is in the project that uses the plugin
class ClaimGiftControllerTests extends AbstractGiftInstanceRelatedUnitTest {
.. my tests
}
And the output (non important parts removed):
| Error Compilation error compiling [unit] tests: startup failed:
...../test/unit/com/myproject/ClaimGiftControllerTests.groovy: 3: unable to resolve class com.myproject.coreservices.service.AbstractGiftInstanceRelatedUnitTest
# line 3, column 1.
import com.myproject.coreservices.service.AbstractGiftInstanceRelatedUnitTest
^
You can put your AbstractGiftInstanceRelatedUnitTest into the src/groovy folder of your plugin, instead of the test folder. That way you can include it in the test cases of the plugin and your other projects.
Related
I am new to Odoo. I am using Odoo 10. I would like to write test cases for a new wizard I created under a module A. I put all my wizard code (views + models) inside wizards directory. I created unit test cases under the path <<module/tests>> followed all the file/class/method naming conventions. When I try to upgrade the module (with test enable) to run unit test cases, all the other modules tests scripts are run but not for the newly created module A. Please suggest what additional changes might be needed to enable test scripts for a newly created module with wizard.
Thank you.
I believe that the structure you have follow is according to the standard way. You can find the structure here Testing Module Structure.
Also please check that the naming on the folder and file in which you wrote the code,
for example - tests/test_todo.py Also, don't forget to update the import in tests/init.py to from. import test_todo
This is because Odoo expects the test module names to start with test_ when it searches for tests belonging to a module Code Reference
Command to Run the testcases:
python ./odoo.py -i module_to_test --log-level=test -d your_database --db-filter=your_database --test-enable --stop-after-init
So here is the overview of my project:
module A contains:
- all boxstore data
- boxstore mock for unit tests in module A
module B contains:
- presenter that has BoxStore injected
- presenterTest needs to mock BoxStore
Followed this link to mock BoxStore and it works fine when I wrote unit tests in module A. When it comes to creating the mock in module B I get NoClassDefFoundError which I understand since module B tests don't know about module A test objects.
So I did the following scenarios:
Added in gradle of module B:
sourceSets { test.java.srcDirs += [etc...] }
So that module B would know about mock objects of module A.
Duplicate mock of BoxStore in module B and use it in tests but BoxStore generates a java file under build folder and because of that I'm unable to create my mock since everything depends on MyObjectBox in order to generate a BoxStore.
Both methods failed :(
Any ideas on how I can unblock myself?
If you're using Gradle, take a look at the java-test-fixtures plugin that has been introduced in Gradle 5.6.2. It introduces a new testFixtures source set where you can place various test data for a specific module and new DSL that allows other modules to reference this data in their tests. In your case, I imagine you'd put the test data in module A's testFixtures directory, and reference it from module B:
// module A
dependencies {
testImplementation(testFixtures(project(":module-B")))
}
I am not able to access configurations properites from grails-app/conf/Config.groovy in my Unit Tests and Integration Tests.
The properties does not exist in grailsApplication.config object
Using Grails 2.5.1 and IntelliJ IDEA 14
What's the best practice to configure my Unit Tests and Integration Tests with Grails 2?
For unit tests:
this is normal behavior, since this is an external dependency and you should not be relying on it, but stubbing it. UnitTestMixin provides a config variable within your unit test, that you can use to stub the values, i.e. config.myValue = xx
For integration test: grailsApplication.config (just inject grailsApplication in you test) should be accessible as usual. You can change the config values, but do not forget to clean up (i.e. restore to original values) after the test.
Solution 1:
IntelliJ > File menu > Project Structure > Modules
Add grails-app/conf folder to Test Source Folders
Solution 2:
Create a separated config file for running tests.
Put a Config.groovy file in test/unit folder and another Config.groovy file in test/integration folder.
The properties will be loaded into grailsApplication.config object
I'm trying to use test support classes within my tests. I want these classes to be available for all different test types.
My directory structure is as follows;
/test/functional
/test/integration
/test/unit
/test/support
I have test helper classes within the /test/support folder that I would like to be available to each of the different test types.
I'm using GGTS and I've added the support folder to the classpath. But whenever I run my integration tests running 'test-app' I get a compiler 'unable to resolve class mypackage.support.MyClass
When I run my unit tests from within GGTS the support classes are found and used. I presume this is because the integration tests run my app in its own JVM.
Is there any way of telling grails to include my support package when running any of my tests?
I don't want my test support classes to be in my application source folders.
The reason that it works for your unit tests inside the IDE is that all source folders get compiled into one directory, and that is added to your classpath along with the jars GGTS picks up from the project dependencies. This is convenient but misleading, because it doesn't take into account that Grails uses different classpaths for run-app and each of the test phases, which you see when you run the integration tests. GGTS doesn't really run the tests; it runs the same grails test-app process that you do from the commandline, and captures its output and listens for build events so it can update its JUnit view.
It's possible to add extra jar files to the classpath for tests because you can hook into an Ant event and add it to the classpath before the tests start. But the compilation process is a lot more involved and it looks like it would be rather ugly/hackish to get it working, and would likely be brittle and stop working in the future when the Grails implementation changes.
Here are some specifics about why it'd be non-trivial. I was hoping that you could call GrailsProjectTestCompiler.compileTests() for your extra directory, but you need to compile it along with the test/unit directory for unit tests and the test/integration directory for integration tests, and the compiler (GrailsProjectTestCompiler) presumes that each test phase only needs to compile that one directory. That compiler uses Gant, and each test phase has its own Grailsc subclass (org.grails.test.compiler.GrailsTestCompiler and org.grails.test.compiler.GrailsIntegrationTestCompiler) registered as taskdefs. So it should be possible to subclass them and add logic to compile both the standard directory and the shared directory, and register those as replacements, but that requires also subclassing and reworking GrailsProjectTestRunner (which instantiates GrailsProjectTestCompiler), and hooking into an event to replace the projectTestRunner field in _GrailsTest.groovy with your custom one, and at this point my brain hurts and I don't want to think about this anymore :)
So instead of all this, I'd put the code in src/groovy and src/java, but in test-specific packages that make it easy to exclude the compiled classes from your WAR files. You can do that with a grails.war.resources closure in BuildConfig.groovy, e.g.
grails.war.resources = { stagingDir ->
println '\nDeleting test classes\n'
delete(verbose: true) {
// adjust as needed to only delete test-specific classes
fileset dir: stagingDir, includes: '**/test/**/*.class'
}
println '\nFinished deleting test classes\n'
}
We are writing unit tests for our business layer running under .NET 4.0. The business layer is a straightforward C# class library that usually runs within SOAP and REST web services. Our application uses log4net within a separate wrapper assembly for logging. The C# code in the logging assembly has an assembly info directive that tells log4net the name of the configuration file, a la-
[assembly: log4net.Config.XmlConfigurator(ConfigFile="AcmeLogging.config", Watch=true)]
Initializing the log4net through the wrapper works fine in the web services. When we initialize it from with our unit test assembly it does not appear to see the configuration file. The configuratino file is configured through properties to be copied to the execution directory, and we do see it in the bin\debug directory. A quick console test program using the logging assembly running from within that same folder works fine. The curious thing is that the behavior problems are intermittent, and pop up on different developers' machines at different times and cannot be cured in any deterministic way.
Stepping through the wrapper assembly code, the log4netLogManager.GetLogger() call appears to return correctly, but the list of appenders returned by log.Logger.Repository.GetAppenders() is empty. Since this incorrect behavior is the same whether the file is in the Bin\Debug folder or not, we believe that it is not seeing the file.
Any clues as to what we're missing about running log4net in the Microsoft Test Framework would be greatly appreciated.
Unit tests are unique in the fact that if you need configuration files in your unit tests you need to include them as deployment items. Here is an example of how I do this within my test class:
[TestClass]
[DeploymentItem("hibernate.cfg.xml")]
public class AsyncForwardingAppenderTest
{
}
In addition to the Deployment attribute you need to Enable Deployment in your test settings. To do this go to Test->Edit Test Settings->. Then click on Deployment area on right. Click the checkbox Enable Deployment.
After doing this and running your test your config file should be located in your test results folder. TestResults\username_machine date stamp\Out. If your config file is not located in this folder it will not work. This is what the DeploymentItem attribute does. It sticks the file in this Out folder.
If you don't want to include the DeploymentItem attribute on every test class what I did was to create a base test class that all of the tests that use log4net inherit from and mark it with the DeploymentItem attribute.