I have test written in spock. Each time when I'm running tests IntelliJ saying that the configuration is wrong - but if I press apply and etc I'm able to run these tests - What I can do, to don't see these messages?
Example of test for which I'm getting this error message:
The configuration which opens after an attempt of running the test:
Last error message:
Any ideas how to get rid of these?
For now I have created issue.
IntelliJ IDEA JUnit configuration stores method name and parameters signature in a single string instance.
While this works for Java (it doesn't allow parentheses in methods names), this fails for other JVM languages.
This issue is not related to Spock, it's reproducible for arbitrary JUnit test class written in Groovy.
Follow YouTrack ticket for updates.
Related
I have two projects in eclipse. The 3DCoordinates project calculates 3D coordinates and makes the conversion from one to another. The second AstroCoordinates project accesses the first project but defines coordinate systems used in astronomy only.
All the JUnit 5 tests for 3DCoordinates run now without problems. I wrote for the AstroCoordinates in a similar manner a coordinate class called HorizontalCoordinates with the appropriate tests. The tests have still errors when running, but, coming to my problem, when I try to debug them, the test stops after opening the Class.class file.
I searched the Internet, but couldn't find an explanation for this – to me – strange behaviour. Do you know about this issue? What can be the reason for it?
Edit:
Here, you can see the result of the normal test run:
The debug test stops without any error message, after the Class.class file opens.
No error messages occur.
If your class is actually named Class, try renaming it.
I am making a piece of software that runs a load test using the JUnit launcher. The problem is that I keep on encountering the following warning WARNING: Error scanning files for URI jar: ... with exception java.nio.file.FileSystemAlreadyExistsException emitted from the JUnit code base due to jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.newFileSystem(ZipFileSystemProvider.java:102) at org.junit.platform.commons.util.CloseablePath.createForJarFileSystem(CloseablePath.java:57).
I am launching the same test across multiple threads. I believe the issue is caused by the .execute() method performing test discovery each time, causing a race condition inside the JUnit code.
I was wondering if there is there currently a way to perform test discovery once in JUnit and then use the same TestPlan to execute the test multiple times? If not is then is there a fix for this problem that allows me to invoke tests which are packaged in the .jar format (unzipping the test .jar is not feasible for my use case).
It seems to me that JUnit no longer supports executing the same test plan repeatedly https://github.com/junit-team/junit5/issues/2379 forcing inefficient test discovery to happen each time leading to the FileSystemAlreadyExistsException. The following class in JUnit may not be thread safe https://github.com/junit-team/junit5/blob/main/junit-platform-commons/src/main/java/org/junit/platform/commons/util/CloseablePath.java
Thanks!
I'm struggling to get the new parallel execution feature of Cucumber-JVM v4.0.0 working.
As discussed here, an argument can be made via CLI to invoke the multi-threading options.
However when i run the below, the request is accepted and the tests are run, but still only one test at a time.
mvn clean test -Dcucumber.options="--threads 4" -Dbrowser=chrome
I'm either over estimating the out of the box functionality or, and more likely, missing some other key configuration or just completely misunderstanding.
Has anyone had any luck in getting this working?
EDIT: Sorry i forgot to mention, it does state that dependency injection has to be used to share state between steps in order for parallel execution to work. Just to confirm, i'm using Pico Container to manage dependency injection.
You cannot use this functionality with Maven. With Maven u need to use the 'parallel' options in junit or testng etc. Refer to the links for them in the same article.
This option is for running the feature files directly from the command line using the cucumber.api.cli.Main class. Refer to this - https://github.com/cucumber/cucumber-jvm/blob/v4.0.0/core/src/main/resources/cucumber/api/cli/USAGE.txt
I am automating system tests using Silk4J. Silk4J is based on JUnit. In addition I am testing my helper classes using pure JUnit tests.
Now I need to tell Infinitest which tests shall be considered for running immediately. I will choose the unit tests only, not the system tests, of course.
The Infinitest preferences have no options. How to tell Infinitest which tests to run (or which tests not to run)?
I have read Is it possible to specify which tests to choose from?, which seems to be a perfect match, but it didn't work for me. The given link returns HTTP 404. I don't have enough reputation to comment nor to start a bounty for updating the question.
It didn't work because the class name needs to include the package name or .* at the beginning to match any package name.
See Infinitest User Guide for details.
I'm working on resolving an odd issue I'm having with my project that has cropped up since we've started working on integration testing. What happens is that I use the "jetty-maven-plugin" to startup an instance of the application, once it's started the "maven-failsafe-plugin" starts to run the integration tests. This much is setup and running well.
What I'm trying to do now is this: I'd like to get a handle on my service layer so that I can setup some fixtures for my tests to run against. Up until now, our integration tests have been pretty simple minded and I'd like to turn it up a notch and test the actual filling out of forms and so on. For this to work, I need to be able to setup some fixtures and then remove them so that these test are reproducible. We're running against a test database that we use for just this purpose.
From what I've read, this is not unreasonable. Nonetheless, when I actually run the tests I get a very odd error message and stack trace. From what I can tell, Maven starts up the application in Jetty without issue. Then the failsafe plugin starts running the test and, once it hits the first integration test, it begins instantiating a Spring instance and context. It correctly pulls in it's properties and configuration files but when it tries to actually inject the service object, I am seeing this error:
Caused by: org.springframework.beans.factory.BeanDefinitionSt
oreException: Unexpected exception parsing XML document from class
path resource [app-config.xml]; nested exception is
org.springframework.context.annotation.Conflicting
BeanDefinitionException: Annotation-specified bean name
'pesticideRoleRepositoryImpl' for bean class
[dao.role.PesticideRoleRepositoryImpl] conflicts with existing,
non-compatible bean definition of same name and class
[dao.role.PesticideRoleRepositoryImpl]
I will spare you all the stack trace, I can make it available at any time. ;-)
I started wondering if I was going about this all wrong and so I went back and setup a test project in much the same way. The test project is far simpler and doesn't have this issue. When it runs the integration tests the service objects are injected without issue. If you are interested, you can take a look at my test project on GitHub.
My Question Is This...
Has anyone seen this error before? Could there be some conditions under which Spring will have this kind of problem?
It's clear to me that with this kind of integration testing, I end up with two Spring containers that use the exact same configuration. I thought this might be the problem but the test project works the same way and doesn't have this issue. I'm also troubled by the fact that even though there are two beans with the same name and class, Spring believes that they are incompatible.
Thank you, any help would be greatly appreciated! :-D
This error occurs when two diferent files contains the same class (bean) definition and are incompatibles, ie oldBeanDefintion.equals(newBeanDefinition) == false
You could check:
Why the scanner is loading this class twice.
Why oldBeanDefintion.getSource().equals(newBeanDefinition.getSource()) = false
Why oldBeanDefinition.equals(newBeanDefinition) = false
You could put a break point on ClassPathBeanDefinitionScanner.isCompatible() or extends ClassPathBeanDefinitionScanner and override isCompatible method and log some useful info to find the error.
As last option, XML BeanDefinitions cannot be overriden by scanned ones, so if you define the bean in XML, scanned clases with same bean name will be ignored.
The selected answer was correct, the root problem was that there were multiple instances of the bean being created. Interesting, though, is that the other instances were mock instances; they were being picked up because they were mixed in with the tests and all of the tests were placed in the classpath.
There are likely many solutions, my fix was to add a "context:exclude-filter" to the "context:component-scan" declaration in my application configuration.