Hello, i'm trying to write e2e tests across severa...

# gradle

[tim]

Hello, i'm trying to write e2e tests across several micro services. I'd like include various micro services in an e2e project but I'm encountering build issues when including them via settings.gralde.kts. For example, one of the included projects, (which is part of a multi project micro service), is causing build errors (i.e., "Unresolved reference" for an included plugin).

Has anyone had success with this type of setup or is there a better approach? I'm going to try symlinking these services into my e2e-testing project next, but that feels a bit hacked together.

[Dariusz Kuc]

if your project builds custom plugin AFAIK you cannot apply it to other projects within the same build

[Dariusz Kuc]

you will need to use composite build

[tim]

okay i haven't used composite builds but the gradle description seems about right

[tim]

i had considered git submodules as an alternative as well

[Dariusz Kuc]

dont think the git submodules will help you

[Dariusz Kuc]

i.e. gradle first will configure the project and then run build

[Dariusz Kuc]

so for configuration you would need the plugin to be already build

[tim]

i already use git sub modules in a similar fashion where every micro service includes a core + testing submodule

[Dariusz Kuc]

libs should be fine as they are just dependencies

[Dariusz Kuc]

plugins -> cant do

[tim]

what do you mean by plugin?

[Dariusz Kuc]

does your build create custom gradle plugin?

[tim]

no

[Dariusz Kuc]

then you shouldnt have to do the composite builds

[Dariusz Kuc]

*you could if it makes for simpler config

[tim]

at least i don't think so 😂 I'm just using the application plugin invoke my entry point/main function

[tim]

i must admit I don't have a good handle on gradle

[tim]

i'll dig into composite builds because ... learnings 🙂 maybe it'll solve some of our project setup challenges!

[tim]

I've just done a small experiment with composites to include the projects i'm currently include as git submoduls ... composites seem promising

[tim]

seems straightforward when including a simple project, but when including a multi-project, I cant import from it into my composite project.

This is what i'm trying to do:

// composite's settings.gradle.kts
include(
  "e2et"
)
project(":e2et").projectDir = File("projects/e2et")
includeBuild("../core")
includeBuild("../multi-project")

and then

// projects/ete2/build.gradle.kts

dependencies {
    ...
    implementation(":core")
    implementation(":multi-project:a")
     ...
}

And finally:

// e2et/src/main/kotlin/App.kt
package e2et

import core.Id
import a.SomethingFromA

main() {
  val somethingFromCore = Id() // works
  val f = SomethingFromA() // doesn't work
}

[tim]

Ahh got it to work! Just needed to replace mplementation(":multi-project:a") with mplementation("multi-project:a")

[tim]

this looks brilliant i think i might remove all git modules in preference for composites!

[tddmonkey]

Rather than doing this - have you considered just deploying your services somewhere and testing against that?

[tim]

So thats exactly what I am doing ... however in writing the tests I need access to the state data classes, repository helpers, etc without having to duplicate them again inside my tests

[tim]

So plan for my e2e test composite project is to have a target environment to test against which could be local, or a remote deployment and then run the tests against it

[tddmonkey]

Feel free to tell me to mind my own business - but if you’re doing e2e tests against multiple services, how come you need access to the source code at all? Isn’t it all done via APIs?

[tim]

It is for the most part yes! There are several reason why I want access to the source code (happy to be told a better way though 🙏)

• We have graphql end points with type safe clients and I don't want to rewrite these
• The domain models that are built by the endpoints are complex enough that in each micro service I've built test helpers to create these objects to then be sent to the endpoint ... i don't want to rewrite these and if a change is made in the service then I want type checking to help identify new/missing types to update
• In some instances an API is not finished and so I need to be able to change a value inside our db (i.e., stuff like changing a status from DRAFT -> APPROVED) in that instance I'd like to use the repository helpers we've built rather than directly accessing the database to tweak a value (again type safety will help keep everything up to date as our system evolves)
I"m sure there are more reasons, but being lazy and not wanting to duplicate code is the primary one :)