I'm upgrading Moq in my unit test projects from a fairly old version (3.2.1) and ran into the infamous MissMethodException on Castle.DynamicProxy.ProxyGenerationOptions.AddDelegateTypeMixin. I ran through all of my projects and upgraded Castle.Core and Castle.Windsor, but now I have a few projects where I still get this exception. The failing projects don't have any references to Castle. Is this expected behaviour, and do I have to add Castle references to unit test projects now in order to use Moq?
Related
I spent a long time trying to run the example tests from here and here.
The #EnableGemFireMockObjects annotation cannot be found and neither can
import org.springframework.data.gemfire.tests.mock.annotation.EnableGemFireMockObjects;
The example tests don't run. Presumably this is missing a Gradle dependency but I can't find a Gradle example in the documentation.
The Spring Test for Apache Geode project (STDG) should build just fine, by running (from the project root directory)...
$ gradlew clean build install
STDG can also be built with Maven, hence the inclusion of a pom.xml file, by running...
$ mvn clean install
NOTE: If you build with Maven first and then later switch to building with Gradle, make sure to remove the target/ directly before building with Gradle.
Additionally, if you setup your IDE (e.g. IJ or STS) with the STDG project, importing from either the Maven or Gradle project models, after building (compiling) the STDG project, you should be able to run the Unit or Integration Tests individually from your IDE as well.
The Maven or Gradle files will ensure that your (test-time) classpath(s) are correct.
As for using STDG outside of the STDG project itself (the tests in STDG are not there for example, but there to test the functionality of STDG itself), see:
Spring Boot for Apache Geode (SBDG): https://github.com/spring-projects/spring-boot-data-geode. Specifically see the auto-configuration module test suite where STDG is used quite extensively.
Spring Session for Apache Geode (SSDG) also extensively uses the STDG project now to test Spring Session functionality with Apache Geode or Pivotal GemFire as the provider: https://github.com/spring-projects/spring-session-data-geode.
Eventually, I will be retrofitting the SDG test suite to use STDG as well, replacing the old test framework inside SDG on which STDG was founded.
Finally...
I did a presentation on the STDG project at the SpringOne Platform 2017 conference, the code of which is here:
https://github.com/jxblum/simplifying-apache-geode-with-spring-data
Here is 1 such test class from that example project:
https://github.com/jxblum/simplifying-apache-geode-with-spring-data/blob/master/simplifying-apachegeode-testing-springdata-complete/src/test/java/example/app/tests/SpringApacheGeodeConfigurationUnitTests.java
I have not updated the project in quite awhile, but is still mostly applicable. Use SBDG and SSDG test suites as definitive examples for using STDG.
Hope this helps.
Per Javalibs I needed to add
implementation 'org.springframework.data:spring-data-geode-test:0.0.11.RELEASE'
to gradle.build dependencies group.
I am in a project environment where Apache Ant is used exclusively to build, test, and deploy production application. I do not have control or influence over this, and it will not change. (ie. I cannot just switch to SBT for this application.)
I have inherited a Scala 2.9.3 application that I am upgrading to Scala 2.12.4. I'm also adding SBT and IDE (Intelli-J) support for LOCAL development, build, testing purposes.
I have everything working building, testing, running locally using ANT, SBT, and the IDE. I'm using scalatest 2.12.3 for most unit tests. But I've run into a problem trying to integrate the Akka Test Kit : https://doc.akka.io/docs/akka/2.5/testing.html
I am unable to create an Ant taskdef for running the tests.
How do I run unit tests against Akka Actors using Ant?
I can provide source code, as needed.
But I don't know how that will help, so please be specific if you want/need to see something.
Thanks!
I've been trying to migrate from Play 2.4 to 2.5 by following the Migration Guide, and I've upgraded my sbt version to 0.13.11 and ensured that I'm using Scala 2.11. I believe I've been able to successfully migrate to 2.5 because I've changed my routes to fit the new default InjectedRoutesGenerator, but I can't seem to use the new play.libs.streams.Accumulator in a custom BodyParser I want to make.
Any ideas as to why I might not be able to reference Accumulator? If it helps, even when I clean, build, and refresh my project in Eclipse, the referenced jars stay as <jar_name>_2.11-2.4.2.jar.
When I run Spring Boot application from Eclipse (STS) as 'Java Application' or as 'Spring Boot App' the app fails because it tries to load configurations (#Configuration) from test classpath.
The thing is that it works for maven based builds correctly, but not for gradle.
The only workaround I see is to rename test package to something else to hide it from classpath scanning.
Overall the question is - how to make it work properly? I'd assume that SpringToolSuite team encounters this problem on a daily basis or I do something incorrectly.
Here's a test project which works when imported as maven, but fails when imported as gradle: https://github.com/mabn/spring-boot-integration-test
Here's a year-old STS issue - is it still relevant?
Here's another one marked as resolved
Similar question about maven projects
I'm using STS 3.7.1
The thing is that it works for maven based builds correctly, but not for gradle.
Yes, unfortunately that is the case. Gradle doesn't deal properly with configuring eclipse's runtime classpath at all. This is even the case with Gradle's own new BuildShip eclipse plugin.
See this issue I recently raised:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=482315
The resolved bug you found is indeed resolved, but it only concerned the maven/m2e case, which is in fact fixable (m2e does this correcty for "Run As >> Java Project" and we adopted a similar fix for "Run As >> Spring Boot App"). However, that fix is maven-specific as the gradle case is not really fixable until this Gradle tooling-api issue ticket is resolved:
https://issues.gradle.org/browse/GRADLE-1777
I had to introduce separation with profiles for this.
Having all test marking with
#ActiveProfiles("srv-test") and main configuration with #Profile({"local", "docker"})
I have a very strange situation. I have a set of eclipse plugin projects which I am using tycho and maven for building them. I used JDBC driver in one of the projects and I have a test plugin to test this project. Since the com.mysql.jdbc plugin was not available in the eclipse p2 repository ( and we don't have our own p2), I imported the jdbc plugin and created an OSGi plugin and add the dependency to my local plugin.
I have multiple eclipse workspaces sat up. Only in the very first workspace that created the test and jdbc plugin, junit tests are working when I run them using eclipse run as -> Junit test command. When others or even me checkout the source codes and try to run the test in different workspaces, this exception is thrown:
java.lang.ClassNotFoundException: com.mysql.jdbc.Driver
I also tried using tycho integration test (runing mvn integration-test) but that doesn't work neither and I still get the same exception. I tried searching for this a lot but I couldn't find the answer.
UPDATE:I think it is not a tycho problem. I just tried to create the eclipse plug in based on com.jdbc.mysql jar. The workspace I created this on is working fine. But as soon as I commit the code and import the project in another workspace the tests stop working. All of the settings are same among two workspaces, one is working the other gets the ClassNotFound exception!
Tycho computes the OSGi runtime based on the transitive dependencies of your test bundle.
You probably have no design-time dependency on the mysql driver bundle (but rather only on the JDBC interfaces it implements)
Try adding a test runtime dependency on the mysql jdbc driver bundle.
See http://wiki.eclipse.org/Tycho/FAQ#How_to_add_a_undeclared_dependency.3F__.28e.g..2C_OSGi_declarative_service.29 on how to do this.
ClassNotFoundExceptions in an OSGi runtime indicate that there is something wrong in the imports and/or export declarations in the OSGi manifests. The most frequent case is that a bundle claims to export a certain package, but doesn't actually have the binaries/class files of that package.
In a Tycho build, this can easily happen if you don't have the entry . in the bin.includes property in the build.properties.