Description
Integration tests invoke dapr run
with a mvn
command. Instead, change how services are invoked for ITs.
1. Use daprd
instead of dapr
Follow instructions in debugging with daprd in IntelliJ to understand how daprd
can be invoked directly. Change DaprRun.java to invoke daprd in a separate process.
2. Run test app as a new thread in same JVM as tests
Now, instead of running the service application as a process by invoking mvn
, run the main function directly as a new thread inside the same JVM as tests. This will avoid having to build a separate fatjar only for test apps. There are environment variables expected by the test app, and those cannot be changed at runtime. On the other hand, all environment variables defined in Properties.java can be overridden via System properties. Since System Properties are global, see this work around on how to have System Properties in ThreadLocal (not ideal for production but OK for tests IMO).
3. Make test app optional in DaprRun.java
Some tests do not need a test app, they just need daprd
. So, offer a new constructor in DaprRun.java
that does not have a test app class. Remove EmptyService.java and use the new constructor for all previous uses of that class.
4. Stopping daprd
Make sure that DaprRun.java
stops daprd
in stop()
method - try gracefully for 1 minute and then forcefully. Because we are not using dapr
anymore, dapr stop
will not work anymore. Stop the process from JVM directly.
5. Verify process leaks.
- Run ITs once and use Sysinternals'
pskill.exe
aspskill daprd.exe
and validate no process was killed. For unix systems, useps auxwww | grep daprd
and validate there is nodaprd
process in the output, only thegrep
process. Feel free to use another solution to validate this if preferred. - Artificially make one of the ITs fail an assertion and run ITs. Replay validation for no
daprd
process leaked. - Artificially throw an exception in the
@Before
method of an IT and run ITs. Replay validation for nodaprd
process leaked.