I have 2 Ratpack applications using Groovy and Gradle (and 2 separate projects), let's call them A and B.
My use case is like: user calls A/foo then A calls B/bar; that is A depends on B (calls are over HTTP, not code dependency).
USER ----> A/foo ----> B/bar
Currently I'm writing functional (integration) tests for A and I've already written some tests where I mocked B's behaviour with an embedded http server (A: LocalScriptApplicationUnderTest, B: Mock). What I want to do now is use real app for B (A: LocalScriptApplicationUnderTest, B: LocalScriptApplicationUnderTest), but how do I do that? Usually I'd add gradle dependency on B to A and then bring up B in embedded server, yet I've no idea how to do the latter part with Ratpack... LocalScriptApplicationUnderTest automatically finds A's ratpack.groovy, how do I make it use B's?
You’ll want to use ServerBackedApplicationUnderTest instead of LocalScriptApplicationUnderTest.
How are you planning on making B’s code available at runtime to A? I’d fat jar B and provide a system property to A’s tests that points to the location of the B fat jar. You’ll then need to load up the B jar in a child (or isolated) class loader, then use LaunchConfigs and RatpackServerBuilder to create a server instance. Take a look at GroovyRatpackMain for the extra properties you’ll need to supply to the launch config (via LaunchConfigs) in order to make the app boot in Groovy mode.
If you want to publish something to GitHub that tries to do this I can take a look.
How are you planning on making B’s code available at runtime to A?
I was hoing to use gradle for that... Deploy (or install) B's jar/fatJar to my maven repo and then in A.gradle add "testCompile 'B'", which would make B available to A's tests. But I'm lost a bit...
Let's put the question this way then: If "example-books" (https://github.com/ratpack/example-books) was on Maven repository and you wanted to create a new gradle project which is basically a functional test of "example-books", how would you do that?
Putting the two apps into the same class loader is going to become problematic quickly for anything serious. You’d want to keep the app under test in a separate process. If you’re going to the trouble of testing against the real app you’d want it to behave like the real thing and not have weird behaviour because of incompatible class paths.
I’d use the Gradle Tooling API to start the remote app, because I’d want to test against source. I’d probably then scrape the output of the started process for the port number and start the app under test injecting the address of the other app.