JUnit: EGA_DEV

E2E_SUITE=java with E2E_TESTS_INTEGRATION=EGA_DEV runs no.elixir.e2eTests.EgaDevIntegrationTest against the live egadev.uio.no environment: six @Order-ed tests matching e2e-egadev stage for stage.

Switching between the two suites

E2E_SUITE is read when dev.sh sources env.sh and re-renders the compose file, so changing it and running ./dev.sh start again rebuilds and recreates the e2e-tests service.

An earlier run’s leftovers do not interfere. Every run namespaces itself: a UUID-named fixture, an accession id of EGAF5 plus ten random digits, a dataset id of EGAD plus eleven. Every assertion matches on those, so a stale file in the inbox or outbox is invisible to the next run rather than fatal to it.

1. Select the JUnit runner and the EGA_DEV class

   export E2E_SUITE=java
   export E2E_TESTS_INTEGRATION=EGA_DEV

2. Export the EGA_DEV credentials and key paths

   export E2E_TESTS_LSAAI_TOKEN=...
   export E2E_TESTS_EGA_DEV_BASE_DIRECTORY=...
   export E2E_TESTS_EGA_DEV_ARCHIVE_PUB_KEYPATH=...
   export E2E_TESTS_EGA_DEV_JWT_PRIV_KEYPATH=...
   export E2E_TESTS_EGA_DEV_JWT_PUB_KEYPATH=...

   env.sh leaves all five commented: per-operator values. Getting them into the container is on you; see the wiring accordion below before starting.

3. Start the stack

   ./dev.sh start

Running outside the container needs two more variables

Environment parses the export-request poll settings with an unguarded Integer.parseInt and Long.parseLong, so leaving either unset throws NumberFormatException: Cannot parse null string while the environment is being constructed, before the first test runs. env.sh supplies both, so a container run is unaffected; an environment assembled by hand, such as an IDE run, needs them explicitly:

export E2E_TESTS_EXPORT_REQUEST_MAX_RETRIES=5
export E2E_TESTS_EXPORT_REQUEST_INTERVAL_IN_SECONDS=10

The Go runner reads the same two variables but defaults them to 0 rather than failing, which skips the outbox poll instead of stopping the run. See the Go EGA_DEV distribution.

why is there more than one selector?

E2E_SUITE picks the runner: go or java. E2E_TESTS_INTEGRATION picks the JUnit test class; the Go runner uses its own E2E_ENV instead and ignores E2E_TESTS_INTEGRATION. Choosing the environment is choosing the program (a test class here, a binary for Go), and the entrypoint refuses an unknown value with a non-zero exit rather than falling back to a default.

which six tests, and what is missing?

Upload through the proxy, ingest, accession, mapping, release, and download via a FEGA export request. No C1, finalize or inbox-cleanup test, same as e2e-egadev.

what does it read that the Go binary does not?

E2E_TESTS_EGA_DEV_JWT_PUB_KEYPATH, which its export test uses and no Go stage does. The Go config still carries the field for as long as this runner reads it, so the two retire together (#851).

how do my key files reach the container?

They do not on their own: the EGA_DEV variables are commented placeholders in the compose template’s environment block, and the e2e-tests service mounts no volume through which host-side key files could reach the container’s filesystem. Wiring both in is operator work.

does E2E_TESTS_RUNTIME point it at egadev?

No. local repoints the endpoints at localhost and the local compose stack’s published ports; it is a host-run switch for the mocked stack, not an egadev one. See running the FEGA class from your IDE for what it is for.