[GSoC 2025] Improved console output for Swift Testing

[smontgomery (Stuart Montgomery)]

Hi @yingchenlin, glad you are interested in pursuing this project!

@yingchenlin

1. The description mentions: “If time allows, implement several alternatives and present them to the community (and the Testing Workgroup) for consideration.“ Should I include all the possible alternatives I have considered in my proposal? Also, is it better to implement a demo as part of my proposal to explain my idea more clearly?

First, I should clarify that there will be one proposal for the GSoC project itself, and there may be a second proposal for the Swift Testing feature addition which would be one deliverable of the GSoC project.

If you're asking about the GSoC project proposal (the first one), I think it might be a good idea to describe the general sort of ideas for enhancing console output that you plan to explore and prototype as part of the project. I don't think it has to include a demo, in fact I doubt most GSoC proposals go that far, but it certainly wouldn't hurt and might be compelling to include mockup drawing(s). I think the full scope of the proposal should be understandable just by reading the proposal document itself though, and I wouldn't recommend relying on readers to (for example) watch a video separately or download and try out a demo application.

@yingchenlin

2. Are there any issues or features that I could start working on to get myself more familiar with the codebase and contribute to swift-testing?

I'm not sure about specific issues since we've mostly resolved the low-hanging fruit bugs in this area of the codebase, but you could consider enhancements to styling of the current console output, such as refining its iconography, colors, etc. (We would need to consider those on a case-by-case basis as to whether they would be accepted, of course!)

@yingchenlin

3. The description also mentions: “Add a new component which receives events from the testing library and decides how to reflect them in console output.“ However, I noticed that files such as Event.ConsoleOutputRecorder and Event.HumanReadableOutputRecorder already seem to do the same thing. How does this new component differ from these existing files? Or is the goal to build on top of these existing files rather than creating a new component?

Yes, conceptually that code you mentioned does fulfill these basic duties today, and a GSoC project could likely begin with those for the general structure. What makes this project different, I think, is that it would implement much more "live" or dynamic output, which does more than just output one or more lines of text for each event. I think a great direction would be to use advanced terminal console techniques to provide live status reporting, which reflect overall progress to the user, and updates as the tests progress. It could also offer configuration so that users could tweak the output formatting, or its level of verbosity, to suite their preferences and let those be saved in a file so they're applied automatically without any CLI flags. These are just ideas to consider, of course.

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] Swift Testing Project.