Debugging of the Engine if it is a separate process

[denis-fokin]

The UintTestBot Java engine can be run from CLI, IntelliJ plugin or as a Java API. The current implementation tightly coupled with bootstrap Java version of the engine process. It is not an issue for CLI and Java API. In case of IntelliJ IDE integration, it is a serious problem. We would prefer to use the same Java for generated test run, engine execution and the concrete executor processes bootstrapping. Such an approach may minimize chances of Class divergence. This approach is difficult to implement on IntelliJ Idea platform because the platform runs plugins in the process of the IDE. Currently, most versions of IDE are bundled with a fork of OpenJDK 11. There is already a version of IDE that is bundled with Java 17.

Let’s assume we successfully extracted the UnitTestBot in a separate process. In order to preserve development process comfortable and rapid we should minimize efforts in the application debugging.

There are several approaches to the debug process:

Old School

Remote debugging is used. A developer is provided with a Debug configuration, the configuration starts and waits for a bunch of debug processes, namely Plugin process, Engine process, Concrete executor process. As soon as a process starts, it connects to a specified port of IDE. All processes are debugged in parallel. In order to stop or kill all the processes, the developer is supposed to use dedicated buttons. Optionally, the developer can specify an option that bound the IDE not to stop the debugging process on Concrete executor completion but wait for another connection on the same port.

Skip First

An alternative solution can skip the plugin process by default. Reasoning for this is importance of the Engine process, which is a cornerstone of the UnitTestBot product.
Remote debugging is used. A developer is provided with a Debug configuration, the configuration starts and runs the Plugin process, after that the debugger waits for the Engine process and optionally opens ports for Concrete executor process.
This approach sounds more robust, because the Engine process is the first-class citizen in the debugging process. Additionally, if the communication protocol works normally, it works as a contract and in most situations, it will be enough to check that the Plugin passes correct data and we are submitting correct data back to the Plugin or to concrete executors.

Conclusion

Extraction of the Engine machinery in a separate process gives benefits from point of implementation encapsulation, safety and flexibility of environment setup. Please, share your thoughts on the topic.

[Domonion]

1. I see a problem with debugging Concrete executor process - there might be a bunch of them with different instrumentations.
2. Logs from Concrete executor process can be provided to the parent Engine process via rd protocol.
3. All approaches can be implemented via Compound run configuration and Remote JVM Debug.
   Run configuration A will provide additional environment variables to the Plugin process which will indicate if Engine process should be started with debug agent that will connect to IDEA via port. Run configuration B of type Remote JVM Debug will listen on port. Both configurations will be started in Compound.

[denis-fokin]

1. Currently we debug them, but it is not the best experience
2. This is great
3. +1