I have a unit test written using scalatest and running fine locally.
But on jenkins it fails with no specific error, just this:
[error] (scalafixAll) scalafix.sbt.ScalafixFailed: TestError
No test method is mentioned in traces, hence no hint about the cause.
How to really find the cause?
Related
After switching to Java 11, sbt tests started to fail with the exception "No configuration setting found for key 'akka'". We are using sbt assembly plugin on the project but since the tests are run not inside jar but using sbt <module_name>/test, looks like there are some issues with building test resources/paths.
List of things I did:
Added concat MergeStrategy for 'reference.conf' file. Jar that is assembled has all files inside and there are no issues with that, so it is only a test step issue.
Checked class path for tests using 'export <module_name>/test:fullClasspath' in sbt before and after migrating to Java 11. They are the same.
Everything else except of a test where I create actor system works good.
Code that creates actor system:
object MyObjectTest extends AsyncFunSuite {
private implicit val system: ActorSystem = ActorSystem("MyActorSystem")
private implicit val ex: ExecutionContext = system.dispatcher
}
At the moment I do not have any ideas what should I check next, so any suggestions would be appreciated.
P.S. running tests inside IDEA works good, but we have CI/CD job that runs tests using sbt test command.
I guess there are some issues when you are using sbt + Java 11. I tried to reproduce this error using a small project with the same configuration but was not been able to do it. However, the issue was fixed using the following option in sbt:
Test / fork := true
According to sbt documentation, this property creates a separate JVM for running all tests. I think all configurations have been set up correctly for another JVM.
Hope this answer will help someone in future.
I have a spring-boot service with spring-security, version -2.1.2.RELEASE. Java-11.0.2
I have test cases written for my API integration testing.
When I run my test cases without code coverage it works, but when I run it with code coverage it fails.
The exception is basically from a configuration file called WebSecurityConfig.java which extends WebSecurityConfigurerAdapter. I have my ldap security check done here and also I am Auto Wiring a settings object called LdapSettings.java which is again a configuration.
Here is a glimpse of the exception which I get when I run with test with code coverage.
java.lang.IllegalStateException: Failed to load ApplicationContext
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Failed to process import candidates for configuration class
Caused by: java.lang.ClassFormatError: Nest member class_info_index 49 has bad constant type in class file com/acumenllc/notifications/config/security/WebSecurityConfig
Also please suggest me if I am doing anything wrong in the design here.
It seems that the stubs are generated too late for the tests to use them. and since I get in the build system following error:
For groupId [example.com] artifactId [my-service] and classifier [stubs] the version was not resolved! The following exceptions took place [org.eclipse.aether.transfer.MetadataNotFoundException: Could not find metadata example.com:my-service/maven-metadata.xml in local (/home/jenkins/.m2...)
at a later stage I get:
--- spring-cloud-contract-maven-plugin:2.0.0.RC1:generateStubs (default-generateStubs) #my-service
I don't really follow what you're trying to do, but you can first run the maven / gradle goal to generate and install the stubs and then run the tests. But that sounds like a smell that in your tests you need your own stubs? That sounds like a bad design
When I try to create the ScalaTest example with this command:
sbt new scala/scalatest-example.g8 fails on TransportException
I get the following:
[info] Set current project to scala (in build file:/Users/chasrmartin/Dropbox/Etudes/Scala/)
[error] org.eclipse.jgit.api.errors.TransportException: git#github.com:scala/scalatest-example.g8.git: Auth fail
[error] at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
[error] at org.eclipse.jgit.api.CloneCommand.fetch(CloneCommand.java:193)
I've tried several workarounds from around the next (eg this SO question) to no avail. It would seem this has to be a simple problem, I got this command from a beginners tutorial.
Update
I got this command from https://www.scala-lang.org/documentation/getting-started-sbt-track/testing-scala-with-sbt-on-the-command-line.html
This project doesn't seems to exists anymore.
Instead I would prefer to run with the normal scala-seed.g8
> sbt new scala/scala-seed.g8
And add the test classes manually.
This is an equivalent tutorial with the same classes and tests.
The scala seed template already comes with the structure you want, with the test dependency. You can run sbt test normally.
Attempting to sbt compile a branch of my project ENSIME (experiment if you're interested) under Java 6 is giving a bizarre compiler warning:
[info] Compiling 48 Scala sources to /home/fommil/Projects/ensime-server/target/scala-2.11/classes...
[error] Class java.lang.invoke.MethodHandle not found - continuing with a stub.
[error] two errors found
[error] (compile:compile) Compilation failed
[error] Total time: 18 s, completed 03-Sep-2014 22:57:44
It works under Java 7.
Calling last reveals nothing more than the classpath of the compile (this would be equivalent to setting --debug level).
I've removed all the plugins from the project, and the problem still shows.
If I remove all my code - leaving just the build system and dependencies - with some stub scala entry points then there is no problem.
However, I can't exactly bisect my source code file because then it doesn't compile.
When the code is compiled, a grep (including binaries) of MethodHandle doesn't give any hits (although there is a jdk8 file in the tests resources, it is not relevant because the problem appears if it is removed).
It is only one (big) patch that has caused the problem (the previous commit compiles ok).
How can I debug this further in sbt? it doesn't want to give any more info
is this a known problem, or can anyone make an informed guess what is going on?
It turns out that this was caused by pulling in Lucene, which requires Java 7.
A bit of an epic message fail from sbt: there doesn't appear to be any way to get it to output anything sensible.