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
Related
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'
}
I don't have Unit Test script yet. I just want to see that the the integration itself is working and show 'Passed' results, is it possible without set of unit test? Currently, I always get Failed status on Summary of Results.
When creating the bot you can uncheck "Perform Test Action" and the bot will not run any unit tests. If you already created the bot you can go the bot under Log Navigator, select it and choose Edit Bot. You will be able to do the same thing there.
Although you haven't created unit tests yourself they are probably already in the project.
If you created your test project from one of the project templates, unit tests are included by default.
The unit tests included by default have a single test that always fails. Locate the unit test and comment out the XCTFail line in the [your project name]Tests.m file
//XCTFail(#"No implementation for \"%s\"", __PRETTY_FUNCTION__);
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.
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.
I have a unit test that deploys a database using a .bak file in the TestInitialize method. I'm running this test from mstest using the dll (not from VS) so I need the .bak file to get copied to the shadow directory that mstest creates.
I don't want to add [DeploymentItem] attributes to every test method, I'm not even sure that would work since the TestInitialize is the method that is consuming this file.
Is there a tag I can put in the project that will guarentee that the .bak file will get copied to the shadow directory when running using MSTest on the test DLL?
Thanks
See Deployment Items: http://msdn.microsoft.com/en-us/library/ms182475(v=vs.80).aspx