[GSoC 2025] Improved console output for Swift Testing

Development GSoC
1

Hello everyone,

My name is Ying-Chen Lin, and I am currently majoring in Computer Science. I have developed a few iOS apps using Swift and have participated in the Swift Student Challenge. Through these experiences, I have become quite familiar with writing Swift code in both Xcode and VSCode, and my primary development environment is macOS.

I really love the Swift programming language, which is why I’m eager to participate in GSoC 2025 with Swift. In particular, I’m interested in the project "Improved console output for Swift Testing"

I have read the project description and expected outcome. Also, I have already forked the repository, cloned it to my computer, and successfully built and tested it in both Xcode and the command line. While reading the project description and codebase, I came up with a few questions:

  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?

  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?

  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?

@smontgomery I would love to hear your thoughts. I would also appreciate any insights and feedback from the community. Thank you!

2 Likes
2

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

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.

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!)

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.

2 Likes
3

Thank you so much for your detailed response. It's really helpful!

I'll start drafting my proposal and will reach out if I have further questions.

1 Like
4

Great to hear! I would encourage posting a draft of the proposal here once it's ready. Then, myself or other community members could give feedback.

5

I have completed the draft of the Swift Testing Proposal. I would be very grateful if @smontgomery and other community members could share any feedback or suggestions.
Thank you so much!

1 Like
6

Hi @yingchenlin, great work on the proposal draft! I requested access to the Google Doc to try to add some feedback comments there but may not get access before the submission deadline.

At a high level, much of it makes sense to me. The details about when you might use CLI flags, environment variables, and user configuration files are helpful. I think there's probably one or two specific details which, if this proposal were put in to action, I might question. As an example, one mockup shows "Expected" vs. "Received" in a == operator expression, and we don't currently have a strong notion of whether the LHS or RHS of a binary expression represents "expected" or "actual". That's minor though.

In your proposed project timeline, I would suggest including a plan to write a Swift Testing feature proposal using the evolution template. In other words, I think the GSoC participant for this project would be expected to culminate their effort in a proposal (separate from the one you just drafted) detailing the improved console output experience. Participation in GSoC, on its own, isn't a guarantee that this contribution would be accepted by the Swift community, so the proposal would make the case for landing the work enabled by default, i.e. in non-experimental capacity.

As a reminder the GSoC application deadline is coming up fast: April 8, 2025 at 18:00 UTC! I encourage you to move ahead with this, in general, and wish you best of luck as things move into the next phase.

Stuart

2 Likes
7

Thank you so much for the detailed feedback!
I’ve just made the final revisions based on your suggestions and submitted the proposal.
I learned a lot throughout the process of exploring the codebase and writing the proposal.
Truly appreciate your help and guidance—thank you again!

2 Likes