From time to time I run into the issue that Grails integration tests the name of which ends in "IntegrationTests" don't work coming up with exceptions that show that GORM methods have not been added to domain classes. After renaming those tests to "*IntegrationTest" (no s at the end) they work fine.
A short example:
class MyIntegrationTests {
#Test
void myTest() {
assert MyDomainClass.count() == 0
}
}
Will fail with the following exception:
Failure: myTest(de.myproject.MyIntegrationTests)
groovy.lang.MissingMethodException: No signature of method: de.myproject.MyDomainClass.count() is applicable for argument types: () values: []
Possible solutions: count(), ident(), print(java.io.PrintWriter), print(java.lang.Object), getCount(), wait()
at de.myproject.MyIntegrationTests.myTest(MyIntegrationTests.groovy:9)
After renaming MyIntegrationTests to MyIntegrationTest the test passes.
Is there some kind of magic happening according to the test's name? All I found in Grails documentation is: "Tests can also use the suffix of Test instead of Tests. " Any ideas?
I eventually found the cause for the different behaviour of "*Test" and "*Tests" myself: Different postfixes change the order in which the tests are being run. To make things worse, the exact order is platform-dependent. Thus, my tests ran locally (OSX) in a different order than on my CI machine (Linux), and thereby produced different results.
Why the exception occurrs in some order is a totally different problem, though, which I haven't figured out (yet).
This should work how you had it originally as long as the file is in the integration folder. Are you sure you didn't have it in the unit test folder and then move it into the integration folder on the rename? Or possibly that you're using intellij and you did a "junit" test run rather than a "grails" one?
The error you're getting seems to imply that grails didn't start up when running your test.
Your test won't be executed if it does not has the suffix Tests.
Copied From Grails documentation home page (http://grails.org/doc/latest/guide/testing.html):
The default class name suffix is Tests but as of Grails 1.2.2, the
suffix of Test is also supported.
j-
Related
I am using Spec Runner to run my test cases, the scenrios are getting called twice.
What might be the issue?
Please find the below scenario and test results attached
ScenarioTestResults
Are they failing scenarios? In the standard configuration SpecFlow+Runner retries failing tests.
To disable the retry of a scenario, you have to set the retryCount parameter in the execution element to 0. See http://www.specflow.org/plus/documentation/SpecFlowPlus-Runner-Profiles/#Execution
Full disclosure: I am one of the developers of the SpecFlow+Runner.
I have a weird situation with Jenkins... We've just started using Gradle for a project at my job and when I run the tests locally with JUnit everything is fine. But when these tests are run by jenkins for the builds of branch "A", only one test fails because of an assert(always the same test).
org.junit.ComparisonFailure: expected: "E[ZZ0530]Z" but was:"E[SY5654]Z"
It looks like the mock is not injected or the mock is ignoring the "when" mocking statement.
Here is the test :
#Test
public void testEvent() {
Date eventDateTime = TimeUtils.parseDate("2013-05-30 00:00:00");
event.setEventDatetime(eventDateTime);
//Mocking the prefix return
Mockito.when(eventCodeHelperMock.getEventCodePrefixFromEvent(event)).thenReturn("EZZ");
//Tested methode
eventWrapper.setSuffix("Z");
// Event code = prefix + date + suffix
assertEquals("EZZ0530Z", event.getEventCode());
}
What is a lot stranger is that when I create a branch "B" from branch "A" all the tests succeeds when the build is created on jenkins.
I've made some research and tried to force an other build, wipe out the current workspace and recreating the job but it didn't work.
Thanks for your help!
I have had similar problems in the past and it has been due to the order in which the junits tests are run. For example, one test modifies the state of an object but you dont see the effects of this till the tests run in a different order, and tests unexpectedly fail. There is not sufficient code in the question you have posted to tell whether this is definitely the case, but I would recommend checking the order in which the tests are being run, and also look at the objects that you are using to determine if there is a problem with the state of those objects being 'dirtied'.
Hello i am new to jbehave and thucydides and the issue i am facing is all the steps are executed in the .java file but it only skips the #when step due to which my test gets skipped. I tried several options but it always marks when as pending when i run the test.
After executing tests case, check your console or report file for story/step error annotation.
Tests that contain no steps are considered to be pending. If one of steps (the "given-when-then" structure) gets PENDING while executing, then whole test gets labelled as SKIPPED. http://www.wakaleo.com/thucydides-one-page/thucydides.html#_defining_high_level_tests_in_junit - 6.2.1
From my experience, most pending steps ("given-when-then") are from bad spelling of a step name/title. Step from .story file and implementation file of a story (your_story.java depending on language) are different. Like "xx yy" =/= "xx yv"
I am trying to work on whats wrong with my lithium current setup. I have installed the Xdebug and verified that remote host can establish the connection as requested.
http://myinstance.com/test/lithium/tests/cases/analysis/logger/adapter/CacheTest?filters[]=lithium\test\filter\Coverage
Please note in fresh installation in local environment , "Coverage" Filter is working as expected.
I added some test code inside the "apply" function in coverage.php but it is not even called !!!! Can some have experience in debugging the above URL ?
I am not able to understand why coverage filter is not called up and executed ...Any hints are highly appreciated !
The filters in the query string are added to the options in lithium\test\Controller::__invoke() and then passed into the test Report object created by the test Dispatcher. The Report object finds the test filter class and then runs the applyFilter() method for that test filter as can be seen in lines 140 to 143 of the current code. So those lines would be another place to debug. Those should wrap the run() method of your tests with this filter code inside the apply() method that uses xdebug_get_code_coverage() and related functions. You said you added test code in the apply method and it isn't called. I'm not sure what the issue is. Are you sure you are pointing to the right server and code location? It is possible to run tests from the command line. Maybe you should try that. See code comments in lithium\console\command\Test or run li3 test --help for info on how to use the command-line test runner.
I can confirm on nginx I also have /test/lithium/tests/cases/analysis/logger/adapter/CacheTest?filters[]=lithium\x5Ctest\x5Cfilter\x5CCoverage in my access log. The \x5C is expected url encoding of the backslash character.
I'm using Specflow with xUnit, should I have an Assert with void Table.CompareToSet() (in the TechTalk.SpecFlow.Assist helpers)
Or it throwing an exception enough? If it throws any sort of exception it should fail (which it does fail ok), but I'm unsure whether I should be stricter by explicitly having an Assert?
Having an exception is enough.
Don't forget, SpecFlow doesn't actually run your tests. It delegates that to NUnit/xUnit/MsTest. So if your code would fail the test in one of those it should also fail in SpecFlow.
BTW, If you write your test first before you write your functional code then of course your test will fail, and that process checks that your fail will work, so you would see for yourself if this is sufficient. ;-)