I nave a servlet that exports some host data using the apache XSSFWorkbook class. It runs fine when running live but when I try to run test code, the constructor is throwing an exception of class not found, org.apache.poi.xddf.usermodel.chart.XDDFChart. It seems odd to me that live code runs without issues but not under unit testing.
Any ideas of how to correct this?
Related
First, important note: This is a project in which the Selenium/Cucumber test suite is working. It's working locally for the developers, and it's working in the Tekton environment.
Second: I have an identical IntelliJ environment as the developers. And other Selenium/Cucumber projects are running fine on my local machine.
When a try to run a fresh copy of the project in question locally, none of the tests start. And, there is no error message.
Normally, this will be cause by missing Glue parameters in the Run/Debug configuration, since IntelliJ for some reason often is unable to add these automatically. This is not the case here.
The test runner when I try to start a specific scenario:
Sorry for the language. The tests are all in Norwegian. But I don't think that matters for seeing the problem.
Normally, when there is an actual error regarding the test step - in the case "Gitt jeg er en vanlig søker" - there would be some info to the right of the steps overview. This is now blank, as can be seen. So, the test stes aren't even started.
The run/debug configuration:
e2e.cucumber.felles is the package where the Java file with the first step definition is located. So, that's not the reason.
Any ideas?
I am fairly new to Griffon and have some experience with Grails.
I have a problem loading a file from the resources directory.
I am using Griffon version 1.4.0.
When I run griffon run-app the following code (inside a Service) to get the location of an XML file works fine:
URL resource = getResourceAsURL('schema.xsd')
assert resource != null : "schema cannot be located"
When I run griffon test-app however the same code produces an assertion error because the returned URL is null. Same behaviour with getResourceAsStream().
This happens in the unit test of said service.
I put the file in ./griffon-app/resources.
What am I doing wrong? Do I have to copy all resources from production to some test resources folder, do I have to edit the build-configuration?
Thanks in advance!
Edit as suggested below I filed a bug report in the griffon-projects issue tracker.
araxn1d is correct, running the tests in integration mode will give you the right answer because the full application gets bootstrapped before tests are run. Now, running this kind of test (a unit test that depends on resources being available in the classpath) encounters a problem because the classpath is not setup correctly. Executing the following command
griffon -Dgriffon.cli.verbose=true test-app --unit --compileTrace=true
will output all classpaths. There you can see that the resources directory points to $USER_HOME/.griffon/1.4.0/projects/<project_name>/resources. If you inspect that directory you'll find the file you're looking for inside griffon-app/resources. This means the test classpath is not accurately configured as it should be $USER_HOME/.griffon/1.4.0/projects/<project_name>/resources/griffon-app/resources instead. This is clearly a bug, most likely found in the $GRIFFON_HOME/scripts/_GriffonClasspath.groovy script. Could you please file a JIRA http://jira.codehaus.org/browse/griffon ticket for it? Thanks!
You should run test-app to run your unit tests. In this case you should mock any refers to real files, otherwise you should implement Integration Tests. Pls see Griffon Testing. Integration tests differ from unit tests in that you have full access to the Griffon application within the test.
I am testing CXF REST services in Karaf using Pax Exam. The tests almost always run without a hitch on my machine. When run in Jenkins (under Maven build) they typically fail. The failures seem random and unpredictable. The error I receive during the failure deals with attempt to run a Karaf command. The commands are executed by the following snippet:
def byteArrayOutputStream = new ByteArrayOutputStream();
def printStream = new PrintStream(byteArrayOutputStream);
CommandProcessor commandProcessor = getOsgiService(CommandProcessor.class);
CommandSession commandSession = commandProcessor.createSession(System.in, printStream, System.err);
commandSession.put("APPLICATION", System.getProperty("karaf.name", "root"));
commandSession.put("USER", "karaf");
commandSession.execute(command)
These are the commands I am trying to execute in the tests setup method:
'features:addurl mvn:org.apache.cxf.karaf/apache-cxf/2.7.2/xml/features', 'features:install http', 'features:install cxf'
This is the exception:
org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: features:addurl
Apparently occasionally Karaf does not start correctly and cannot process these commands. The error like this one happen randomly in different tests on different Karaf commands. On my machine they are more likely to happen if the machine is under load.
What may cause Karaf to behave in such a manner? How to prevent these errors from happening?
Thank you,
Michael
There is is also pax-exam-karaf, it also has a feature installer which is usable from the configuration. If you want to stick to the "manual" installation you shoul make sure the features service is installed beforehand. For example let the service be injected.
I have a third party library that I'm attempting to incorporate into a simulation. We have the static library (.a), along with all of it's runtime dependencies (shared objects). I've created a very simple application (in C) that is linked against the library. All it does is call an initialization function that is part of the third party library's API, and exits. When I run this directly from the command line, it works fine. If I submit the executable to our Condor grid, it fails with a seg fault on strncpy (libc.so.6). I've forced condor to only run the executable on a particular machine, and if I run it directly on that machine, it works fine.
I'm mostly a Java programmer... limited amount of native coding experience. I'm familiar with tools such as nm, ldd, catchsegv, etc... to the point where I can run them. I don't really know where to start looking for an issue though.
I've run ldd directly on the executing machine, and via a script submitted through condor, along with my executable. ldd reports the same files in both cases.
I don't understand how running it directly would work, but it would fail being run by condor. The process that ultimately executes the program, condor_startd, is a process that starts as root, and changes its effective uid to the submitter. Perhaps this has something to do with it?
Don't know why this would cause an issue, but the culprit was the LANG environment variable. It was not set when running under Condor, but was set to US_EN.UTF-8 when running locally. Adding this value to the condor execution environment fixed the problem.
Is it possible to quickly run single/all integration test in a class quickly in Grails. The test-app comes with heavy baggage of clearing of all compiled files and generating cobertura reports hence even if we run single integration test, the entire code base is compiled,instrumented and the cobertura report is getting generated. For our application this takes more than 2 minutes.
If it was possible to quickly run one integration test and get a rapid feedbck, it would be immensely helpful.
Also, is it important to clean up all the compiled files once the test is complete? This cleaning is fine if we run the entire set of integration test, but if we are going to run one or two tests in a class this cleaning and re-compiling seems to be a big bottleneck for quicker feedback to developers.
Thanks
If you have an integration test class
class SimpleControllerTests extends GrailsUnitTestCase {
public void testLogin() {}
public void testLogin2() {}
public void testLogin3() {}
}
You can run just one test in this class using:
grails test-app integration: SimpleController.testLogin
However, you will still have to incurr the time penalty required for integration testing (loading config, connecting to DB, instantiating Spring beans, etc.)
If you want your tests to run quickly, then try to write unit tests rather than integration tests.
It is the intention of the integration test to do this whole compiling, data base creation, server starting, etc. because the tests should run in an integrated environment, as the name implies.
Maybe you can extract some tests to unit tests. These you can run in Eclipse.
You can switch off Cobertura by placing the following code in your grails-app/conf/BuildConfig.groovy:
coverage {
enabledByDefault = false
}
Like you stated, the majority of time is setting up the application environment, injecting beans and doing the dynamic class annotations. You can speed up your integration test cycle by only loading this once, by running your tests in the grails REPL.
However, the tradeoff is that there are dynamic reloading issues in the REPL. If you see random weirdness, exit the REPL and reload.
$> ./grailsw --plain-output
|Loading Grails 2.5.3
|Configuring classpath
|Enter a script name to run. Use TAB for completion:
grails> test-app -integration
... (loads some things)
...
grails> test-app -integration
... (faster loading)
And to reply to the other commenters - integration tests are useful as well, there is some code that cannot be tested with a unit test (for instance, testing HQL or SQL queries).