I am trying to write an integration test using h2 db, I am getting an error as "error: cannot access BlockJUnit4ClassRunner" at the line #RunWith()
Can any one suggest something please? I have no clue, even If I comment out everything in the test it would not build and give the same error, so I don't think what's in the test that causing the issue
#RunWith(SpringJUnit4ClassRunner.class)
#TransactionConfiguration(defaultRollback = true)
#ContextConfiguration(locations = { "classpath:test-applicationContext.xml" })
public class WfsDBTest extends AbstractTransactionalJUnit4SpringContextTests {}
Please help
thanks
It looks like you use wrong version of JUnit.
Make sure that you use JUnit 4.x and there are no other versions of JUnit in your classpath. Try to use the latest version.
Related
So I recently started working on Cucumber and have been facing this issue.
This is the hierarchy of my module
As you can see this is submodule in my Spring Boot application (AcceptanceTests), so there are no main methods in it.
This is my CucumberSpringContextConfiguration class
#SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
#CucumberContextConfiguration
public class CucumberSpringContextConfiguration {
}
This is my CucumberIntegrationTest class
#RunWith(Cucumber.class)
#CucumberOptions(
features = "src\test\resources\feature",
plugin = {"pretty", "html:target\\cucumber"},
glue = "com.#####.########.cucumberspringboot.cucumberglue"
)
public class CucumberIntegrationTest {}
I tried running this code with a main class (src/main/java),the code compiled successfully. But since that is not my requirement I removed it and now I am getting below error -
SEVERE: Exception while executing pickle
java.util.concurrent.ExecutionException:
io.cucumber.core.backend.CucumberBackendException: Please annotate a
glue class with some context configuration.
For example:
#CucumberContextConfiguration
#SpringBootTest(classes = TestConfig.class)
public class CucumberSpringConfiguration { }
Or:
#CucumberContextConfiguration
#ContextConfiguration( ... )
public class CucumberSpringConfiguration { }
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at io.cucumber.core.runtime.Runtime.run(Runtime.java:93)
at io.cucumber.core.cli.Main.run(Main.java:92)
at io.cucumber.core.cli.Main.main(Main.java:34)
Caused by: io.cucumber.core.backend.CucumberBackendException:
Please annotate a glue class with some context configuration.
Please suggest how to achieve this without using main class.
io.cucumber.core.cli.Main.run(Main.java:92) at io.cucumber.core.cli.Main.main(Main.java:34)
This part of the stacktrace shows you are using the Cucumber CLI rather than CucumberIntegrationTest. So you are probably running your feature file through IDEA. Presumably you clicked the green play icon in the gutter of a feature file.
Unfortunately Intelij IDEA makes some assumptions and bad guesses. If you look at the run configuration that was created you'll see that there is a command line with --glue argument that probably points at features. You'll have to change this manually.
It is currently unnecessary to guess the --glue argument and I have already asked the team behind Intelij IDEA to fix this at IDEA-243074 but the issue has gotten zero attention so far. You can upvote it, maybe something happens.
You can also avoid this problem by putting your feature files in a different location e.g. src/test/resources/com/#####/########/cucumberspringboot. Becaus this is the parent package of cucumberglue Ingelij IDEA is less likely to mess things up.
Also note: you are currently using JUnit 4 to run Cucumber. Spring Boot prefers using JUnit 5. You should use the Cucumber JUnit Platform Engine. You can find a minimal example here.
In my SpringBoot application, I have one test classes inside /src/test/java.
For Testing (Unit Tests). I want to use the In memory H2 database. I have the following Database Url
jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;INIT=runscript from 'classpath:/schema.sql'\\;runscript from 'classpath:/data.sql'
So when I run the test. the database is created and the scripts (schema.sql and data.sql) runs correctly as expected. it creates some tables and puts some test data over there.
Now the problem is I added another Test class and written some tests there. so whats happening now is, first test class runs succesfully, but when the second class loads, it tries to run the scripts (schema.sql and data.sql) again on the in memory H2 database. and that obviously fails. because those tables are already there in the DB.
Can anyone please suggest how Can i achieve the behaviour I want. such that my scripts should run only once and then all the test classes should use that same database.
My Test class example is below
#RunWith(SpringRunner.class)
#SpringBootTest()
public class CreateServiceTest {
#Autowired
private CreateRepo repo;
#Test
public void testCreation(){
// test code here
}
With spring boot the h2 database can be defined uniquely for each
test. Just override the data source URL for each test
#SpringBootTest(properties =
{"spring.config.name=myapp-test-h2","myapp.trx.datasource.url=jdbc:h2:mem:trxServiceStatus"})
The tests can run in parallel.
refer: https://stackoverflow.com/a/49644877
im trying to setup a cucumber with spring project to use autowiring and spring config options (application.yml). Now that i created a runner class to pass parameters from outside executing runs on following exception:
Weird is, i have a class exactly with the proposed annotations, so i guess it's not found and something on the project structure is off, but i don't get what exactly.
Here is my project structure:
src.main.java.package.config.SpringConfig.java
src.main.java.package.steps.StepsSpringConfig.java
src.test.java.package.runner.CucumberRunner.java
SpringConfig.java
#ComponentScan("package")
#EnableConfigurationProperties{PropertyClasses}
StepsSpringConfig.java
#SpringBootTest(classes = SpringConfig.class)
#CucumberContextConfiguration
All Step classes extend from this class
CucumberRunner.java
#RunWith(Cucumber.class)
#CucumberOptions(steps = path/to/features, glue = {src.package.steps, src.package.config})
In my JUnit RunConfig I use this runner class
When i run i get the error on the screenshot above. What am i missing?
Im using the latest version of IntelliJ (2021.2.2)
Im using Spring 2.3.12 and cucumber-junit 6.8.0
Ok im dumb, the solution is found here: Cucumber options annotation
i specified the glue path like "src.main.java.package.steps" but it needs to be just "package.steps" and it works fine
My Spring Boot 1.5.17 (Spring 4.3.20) server works fine with bootRun or when deployed.
However, I have an Oracle DataSource that fails only when unit-testing:
java.lang.AssertionError: Server is sending a non-null replay context
but our replayModes=[]
A Google Search for this error doesn't have exact results.
I am able to unit-test with a different Oracle database.
I get the error with a full Application testing context
#RunWith(SpringRunner.class)
#SpringBootTest(
webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT,
classes = { TestingUserConfiguration.class, Application.class }
)
As well as just the single DataSource config and Service
#RunWith(SpringRunner.class)
#SpringBootTest(classes = {
MyDbConfig.class,
MyService.class
})
Both oracle.jdbc.pool.OracleDataSource and oracle.jdbc.replay.OracleConnectionPoolDataSourceImpl have the error.
UCP makes no difference.
OracleConnectionPoolDataSourceImpl has a different error:
java.sql.SQLException: Unsupported feature
Tried upgrading from OJDBC 12.2 to 2018.3, no difference.
Has anyone seen this error before?
Any ideas on why it only appears with Spring unit tests?
After much head scratching, I found that doing this in the test suite:
static {
ClassLoader.getSystemClassLoader().setPackageAssertionStatus("oracle.jdbc.driver", false);
}
Solved My issue, I am sure this is a bug in the oracle.jdbc.driver.T4CTTIfun class
You can add "-da:oracle..." to your JAVA_TOOL_OPTIONS to turn off oracle asserts. To get around this.
Trent
I guess am trying to get a corner case to work here. In my current project there are about 20 integration tests. One new integration test requires #EnableAsync to make the test work:
#RunWith(SpringRunner.class)
#EnableAsync
#SpringBootTest(webEnvironment = WebEnvironment.NONE)
public class MyITest {
:
}
When run alone, this test works fine.
Considering Maven and Eclipse' execution of tests in one project and knowing that the environment is only created once and reused (or soft-reset) for all integration tests, it's somewhat a requirement that this integration test runs first. However, that's (nearly?) never the case.
Therefore, this integration test (nearly?) always fails. One obvious solution is to add #EnableAsync to all integration tests. However, that's a bad dependency which I bet is broken once somebody adds another integration test and forgets this requirement.
I'm looking for a way to force the SpringRunner to completely reset the context and really start it from scratch also looking at #EnableAsync. Ideally that way includes to flag that SpringRunner has to reset the context (i.e., remove the #EnableAsync) after the test, too. That way any order of execution would ensure that only that very one test has the #EnableAsync.
Is there a way to do this? Or can I manually turn on/off the async-stuff by code in a #Before/#After method?
take a look at DirtiesContext
Not sure if this is what you're looking for.
Possible duplicate of: How do you reset Spring JUnit application context after a test class dirties it?
Whow, I think I just found out by accident... What I have now:
#RunWith(SpringRunner.class)
#EnableAsync
#SpringBootTest(webEnvironment = WebEnvironment.NONE, classes = {
ClassWithAnAutowiredAsyncDependency.class // <=== difference!!! ===>
})
public class MyITest {
:
#Autowired
private ClassWithAnAutowiredAsyncDependency mine;
:
}
It seems as if the given classes are reset (specially?) or at least the autowiring happens in there again or something. I can't explain it any different.
I'm sure that this integration test is not the first integration test being run and still the asynchronous bit seems to be in place.
Well, test is green, it works...