[GSoC 2025] Swift Testing Project

[smontgomery (Stuart Montgomery)]

Hi @M7md-Ebrahim, glad you are interested in pursuing this project!

(For context, since I don't believe it has been linked in this topic yet:) This is regarding the GSoC 2025 project idea "Improved console output for Swift TestingSwift.org - Project Ideas for GSoC 2025".

@M7md-Ebrahim

• This great PR seems highly relevant to our goal. What do you think about considering it for this project? Would it align well with the direction we want to take?

Yes, I absolutely think that style of dynamic console output is relevant to this project. Not necessarily saying this project should directly follow or copy that, but I agree some of the concepts (like showing a live-updating view of in-progress tests) should be considered.

@M7md-Ebrahim

• You mentioned the IPC mechanism for communication between the harness process and runner process. Could you explain more about how this works in practice? Also, is the harness process similar to the current event system in Swift Testing, or is it fundamentally different?

This IPC mechanism doesn't exist yet, but some of the initial build blocks are in place for it. See the documentation in the Swift Testing repo for the JSON event stream as well as ST-0002: A stable JSON-based ABI for tools integration. The eventual idea is that we will want there to be a "harness" process which acts as the supervisor or parent process of the process which runs tests. The child runner process would pass a serialized version of events up to the harness process. The harness would become responsible for producing all human-readable console output. There would be several benefits to this architecture, including: if the runner unexpectedly crashes the harness could relaunch it, and stdout/stderr output from the runner could be isolated so as not to distract from the results.

When it comes to this GSoC project, because we don't expect to have rearchitected and introduced a formal harness yet, this improved console output should be done in the same process that output is currently generated: in the runner. But the code should be factored in such a way that would make it straightforward and easy to move to a harness process in the future.

Hope that helps, and let me know if you have further questions. I believe the GSoC 2025 application phase has now begun, so I encourage you to begin thinking about a written proposal if you're interested in pursuing this.

Stuart

Note: There is one other community member who I noticed has posted on the Forums and expressed interest in this GSoC project idea: see [GSoC 2025] Improved console output for Swift Testing.