DEV Community: Yoshinori Imajo

Running Asynchronous Setup Side Effects in `@Test` with Swift Testing

Yoshinori Imajo — Thu, 23 Oct 2025 07:55:56 +0000

🧩 Introduction

Sometimes in test code, we want to perform side effects just before a test case runs — without placing that setup logic directly inside the test function.

Swift Testing supports Arrange phases before a test, but it doesn’t (yet) allow asynchronous or side-effectful setup directly in @Test.

Sure, helper functions work — but what if we could express Arrange–Act–Assert (AAA) visibly and cleanly inside Swift Testing itself?

If you have suggestions for improvements, feel free to comment.

🎯 Goal

Here’s what we’d like to achieve:

// MARK: - Test case and its preparation
@Test(
    // MARK: Arrange
    // Ideally, asynchronous side effects could run here
)
func testCase1() async throws {
    // MARK: Action
    // MARK: Assertion
}

In short, this post shows that — yes, you can do this.
@Test already supports parameterized tests, so we can leverage that mechanism to perform async setup work.

💡 Motivation

You might think:

“You could already do this using TestTrait or TestScoping’s setUp().”

And yes — you’d be right. But I wanted per-test asynchronous setup, not a global one.

Example: testing a “read” operation might require writing data first. I want that Write to live right next to the test that reads it — not far away in a shared helper.

Of course, helper functions are an option, but they separate intent and context. I wanted my test’s Arrange to be visually and contextually adjacent to the test logic itself.

🧩 Example: Using Realm

Let’s look at a concrete example using Realm.

Realm is common in iOS apps, but it can behave unexpectedly across threads.
Testing concurrency-heavy code with Realm requires careful context handling.
In particular, the in-memory configuration is sensitive to scope.

Here’s a test that demonstrates how to perform async setup directly via @Test:

@Test(MyTestTrait(
    actions: [ // Perform pre-test side effects here
        { realm in
            print("Arrange Step 1:", realm, Thread.current)
        },
        { realm in
            // Another example — not always necessary
            print("Arrange Step 2:", realm, Thread.current)
        }
    ]
))
func example() async throws {
    guard let realm = RealmContext.current?.realm else {
        XCTFail("Realm not injected")
        return
    }

    // Perform Realm tests
    print("🧪 Using realm:", realm, Thread.current)
}

🧩 TaskLocal Context

We can define a TaskLocal context to safely inject the Realm instance:

struct RealmContext {
    @TaskLocal static var current: RealmContext?
    let realm: RLMRealm
}

This allows RealmContext.current to be available anywhere inside the async test body.

⚙️ Implementing the Trait

Here’s a minimal MyTestTrait implementation that performs setup and cleanup around the test body:

struct MyTestTrait {
    // These actions are passed in from the test
    let actions: [@Sendable (RLMRealm) async throws -> ()]
}

extension MyTestTrait: TestTrait, TestScoping {
    func provideScope(
        for test: Test,
        testCase: Test.Case?,
        performing function: @Sendable () async throws -> ()
    ) async throws {

        // Setup Realm (in-memory)
        let realm = {
            let config = RLMRealmConfiguration.default()
            config.inMemoryIdentifier = UUID().uuidString
            RLMRealmConfiguration.setDefault(config)
            return RLMRealm.default()

            // NOTE: This modifies the global .default configuration.
            // It can leak into other tests, so use with caution.
        }()

        // Execute Arrange steps sequentially
        for action in actions {
            try await action(realm)
        }

        // Run the test body within the scoped context
        try await RealmContext.$current.withValue(.init(realm: realm)) {
            try await function()
        }
    }
}

This keeps setup logic close to your test definition,
while still leveraging Swift Testing’s structured concurrency and scoping.

🧩 Takeaways

✅ You can use parameterized traits to perform async setup directly in @Test
✅ TaskLocal makes dependency injection ergonomic and thread-safe
⚠️ Beware: changing Realm’s global configuration can leak between tests
🚫 localActions = actions–style “safety copies” are unnecessary; traits aren’t shared across tests
🧠 Prefer direct initializers to redundant static factories

Notes

Tested on Swift 6.1, Xcode 16.3
RLMRealm is not Sendable — protect access carefully
For projects using DI frameworks, this approach may overlap with existing patterns
Yes, whether you should test side effects is a valid philosophical question

Building an MCP Server to Use ChatGPT Without API Keys - A Novel Approach Using macOS Shortcuts

Yoshinori Imajo — Mon, 21 Jul 2025 10:34:16 +0000

Introduction

Ever wanted to integrate ChatGPT with Claude and other AI tools without dealing with API keys or wasting your monthly subscription?

Instead of the traditional API approach, I solved this challenge using macOS Shortcuts - an unexpected solution that combines existing resource utilization, security, cost efficiency, and simplicity in one innovative approach.

Today, I'll share how I built an MCP server that integrates the Model Context Protocol (MCP) with macOS Shortcuts to solve this exact problem.

What I Built

mcp-server-chatgpt-mac-app

This MCP server enables communication with ChatGPT through the macOS ChatGPT app and Apple Shortcuts, completely bypassing the need for API keys.

The Problems We're Solving

Many developers face these common challenges:

💰 Cost Issues

Expensive API usage: Heavy tasks can result in unexpected billing charges
Wasted subscriptions: ChatGPT Plus costs $20/month but can't be used via API

🔄 Claude Code Limitations

Infinite debugging loops: Weaker LLMs get stuck repeating the same fixes endlessly, never completing tasks

The Core Innovation: Leveraging macOS Shortcuts

The key breakthrough was utilizing macOS Shortcuts functionality.

Why This Approach is Revolutionary

Leverage Existing Resources: Maximize your already-paid ChatGPT Plus subscription
Enhanced Security: No API key management required
Cost Effective: Zero additional integration costs
Simplicity: Uses only macOS standard functionality

How It Works

The system uses a temporary file-based communication pattern to pass prompts to the shortcuts system, then processes responses back through the MCP protocol.

Key Benefits: Solving Claude Code's Weaknesses

The biggest advantage of this MCP server is compensating for Claude Code's limitations.

Claude Code's Challenges

While Claude Code is an excellent tool, it has some issues:

Band-aid coding: Applies quick fixes without considering fundamental design
Debug loops: Gets stuck repeating similar fixes indefinitely
Rigid thinking: Fixates on one approach, unable to consider alternatives

Rescue with ChatGPT o3

When Claude Code gets stuck in a loop, you can consult ChatGPT o3 via this MCP server:

Ask ChatGPT: "This code has a bug with ○○, but Claude Code keeps repeating similar fixes. What's the fundamental solution?"

This provides:

Different perspective: Analysis from a different angle than Claude
Root cause identification: Understanding essential problems, not just surface issues
Design-level suggestions: Architectural approaches that rethink the problem

Real Usage Example

When Claude Code gets stuck in loops, using this MCP server to consult ChatGPT o3 gives you:

Different perspective: Analysis from a different angle than Claude
Root cause identification: Understanding essential problems, not just surface issues
Design-level suggestions: Architectural approaches that rethink the problem

Usage

1. Prerequisites

# Install ChatGPT app (official from OpenAI)
# Set up "Ask ChatGPT on Mac" shortcut

2. Global Installation

claude mcp add chatGPTOnMac -s user \
  -- npx mcp-server-chatgpt-mac-app

3. Project-Local Setup

// .mcp.json
{
  "mcpServers": {
    "chatGPTOnMac": {
      "command": "npx",
      "args": ["mcp-server-chatgpt-mac-app"],
      "cwd": ".",
      "env": {}
    }
  }
}

How It Works in Practice

You can give Claude natural instructions like:

Ask ChatGPT: "What's the best way to optimize this code?"

The flow:

MCP server writes prompt to temporary file
macOS shortcut executes
Shortcut sends prompt to ChatGPT app
ChatGPT response returns via Claude

Key Learnings

Power of macOS Automation

macOS Shortcuts proved more powerful than expected:

CLI invocation: shortcuts run command available
File input: -i option enables file-based input
App integration: Tight integration with third-party applications

MCP Protocol Flexibility

I gained real appreciation for the Model Context Protocol design:

Pluggable: Easy to add new functionality
Type-safe: Robust schema definitions
Standardized: Consistency across different AI tools

Conclusion

This project reinforced the importance of "maximizing existing resources through creative engineering." Without using API keys, we achieved cost-effective and secure ChatGPT integration by leveraging Apple Shortcuts - a standard system feature.

If you're paying for monthly subscriptions but still paying separate API fees, this approach is definitely worth trying!

Errors in the stream switched using flatMap are not involved upstream in Combine framework.

Yoshinori Imajo — Sun, 29 Nov 2020 07:33:17 +0000

The Publisher will terminate the stream in case of an error. However, if the Publisher switched by flatMap fails, the upstream before the switch does not terminate.

(This would be a big difference from RxSwift.)

Using flatMap sample

import Foundation
import Combine

let cancelable = (1...3).publisher
    .handleEvents(receiveOutput: {
        print("🥷 handle output: \($0)")
    }, receiveCompletion: { _ in
        print("🥷 handle completion:")
    }, receiveCancel: {
        print("🥷 handle cancel:")
    })
    .setFailureType(to: NSError.self)
    .flatMap { value -> Future<String, NSError> in
        print("🍏 flatMap: \(value)")
        return Future<String, NSError> {
            guard value == 1 else {
                $0(.failure(NSError(domain: "test", code: 1)))
                return
            }

            $0(.success("\(value)"))
        }
    }
    .sink(receiveCompletion: {
        switch $0 {
        case .finished:
            print("🍎 sink finished:")
        case .failure(let error):
            print("🍎 sink failure:", error)
        }
    }, receiveValue: {
        print("🍎 sink received: \(String(describing: $0)) 🎉")
    })

This code has the following output:

🥷 handle output: 1
🍏 flatMap: 1
🍎 sink received: 1 🎉
🥷 handle output: 2
🍏 flatMap: 2
🍎 sink failure: Error Domain=test Code=1 "(null)"
🥷 handle output: 3
🥷 handle completion:

Notice the 🥷 emoji; despite the sink failure, the output will see that the element is handled 3 and even sent to completion.

Using PasshtoughSubject & flatMap sample

Of course, using PassthroughSubject doesn't change the result.

import Foundation
import Combine

let subject = PassthroughSubject<Int, NSError>()

let cancelable = subject
    .handleEvents(receiveOutput: {
        print("🥷 handle output: \($0)")
    }, receiveCompletion: { _ in
        print("🥷 handle completion:")
    }, receiveCancel: {
        print("🥷 handle cancel:")
    })
    .flatMap { value -> Future<String, NSError> in
        print("🍏 flatMap: \(value)")
        return .init {
            guard value == 1 else {
                $0(.failure(NSError(domain: "test", code: 1)))
                return
            }

            $0(.success("\(value)"))
        }
    }
    .sink(receiveCompletion: {
        switch $0 {
        case .finished:
            print("🍎 sink finished:")
        case .failure(let error):
            print("🍎 sink failure:", error)
        }
    }, receiveValue: {
        print("🍎 sink received: \(String(describing: $0)) 🎉")
    })

subject.send(1)
subject.send(2)
subject.send(3)
subject.send(completion: .finished)

This code has the following output:

🥷 handle output: 1
🍏 flatMap: 1
🍎 sink received: 1 🎉
🥷 handle output: 2
🍏 flatMap: 2
🍎 sink failure: Error Domain=test Code=1 "(null)"
🥷 handle output: 3
🥷 handle completion:

After all, the upstream doesn't care if the downstream switched stream fails. This may cause the stream execution process to continue unnecessarily.

My guess is that to account for this, we would have to control it with subscriptions.

Combine.framework Scheduler recap (Diagram)

Yoshinori Imajo — Sat, 31 Oct 2020 08:44:51 +0000

Diagram to understand about Combine Scheduler

Combine allows you to switch queues using a scheduler.

I'll recap the methods receive(on:options) and receive(on:options), which are used by the scheduler to do so, as shown in the diagram below.

The follwing image was added to the slides in WWDC19 Introducing Combine session.

The following is a summary of the timing for executing the queues specified by the scheduler.

receive(on:options)
- Timing of Queue Execution
  - When receiving an element.
    - receive(_ input:)
  - When receiving an completion.
    - receive(completion:)
subscribe(on:options)
- Timing of Queue Execution
  - When Publisher is subscribed by a subscriber.
    - subscribe(_:)
    - sink(receiveValue:)
    - sink(completion:receiveValue:)
    - ...etc
  - When a Subscriber successfully subscribes to a Publisher and requests an element.
    - receive(subscription:)
  - When Publisher is canceled.

Scheduler Protocol

The Scheduler is a Protocol, and the following required methods are called

schedule(options:_:)
schedule(after:tolerance:options:_:)
schedule(after:interval:tolerance:options:_:)

Reflections on Apple's Document

For these reasons, see Apple's documentation.

receive(on:options)

Sample code for receive(on:options) is shown below.

let jsonPublisher = MyJSONLoaderPublisher() // Some publisher.
let labelUpdater = MyLabelUpdateSubscriber() // Some subscriber that updates the UI.


jsonPublisher
    .subscribe(on: backgroundQueue)
    .receive(on: RunLoop.main)
    .subscribe(labelUpdater)

The document further states

receive(on:options:) changes the execution context of downstream messages.

This is specifically the case for the
Queueing is specified when receive(_ input:) and receive(completion:) are called.

However, it does not affect the call to receive(subscription:).

Note
receive(on:options:) doesn’t affect the scheduler used to call the subscriber’s receive(subscription:) method.

subscribe(on:options)

Sample code for subscribe(on:options) is shown below.

let jsonPublisher = MyJSONLoaderPublisher() // Some publisher.
let labelUpdater = MyLabelUpdateSubscriber() // Some subscriber that updates the UI.


jsonPublisher
    .subscribe(on: backgroundQueue)
    .receive(on: RunLoop.main)
    .subscribe(labelUpdater)

The document further states

subscribe(on:options:) changes the execution context of upstream messages.

Using subscribe(on:options:) also causes the upstream publisher to perform cancel() using the specified scheduler.

In other words, when Publisher is requested to the Subscriber for when to specify the execution of the scheduler.

And when the Publisher is canceled, it is also executed by the scheduler.

(By the way, I implemented the Scheduler, and the scheduler method is also executed when the Publisher is subscribed to the Subscriber. The OSS pointfreeco/combine-scheduler uses it to get the events on subscribe.)

Comparison with Rx.

The next topic is the difference compared to the Scheduler in Rx.

In Rx documentation, there are two operators, observeOn and subscribeOn, which are shown in the marble diagram.

This behavior is probably the same in the Combine.framework.
Combine's behavior is investigated in the following code.

let receiveQueue1 = DispatchQueue(label: "[Receive queue 1]")
let subscribeQueue = DispatchQueue(label: "[Subscribe queue]")
let receiveQueue2 = DispatchQueue(label: "[Receive queue 2]")

Just(1)
    .flatMap { value -> AnyPublisher<Int, Never> in
        let label = String(validatingUTF8: __dispatch_queue_get_label(nil))!
        print("flatMap execute queue: \(label)") // => [Subscribe queue]

        return Just(value).eraseToAnyPublisher()
    }
    .receive(on: receiveQueue1)
    .map { value -> Int in
        let label = String(validatingUTF8: __dispatch_queue_get_label(nil))!
        print("map execute queue: \(label)") // => [Receive queue 1]

        return value * 10
    }
    .subscribe(on: subscribeQueue)
    .receive(on: receiveQueue2)
    .sink(receiveValue: {
        let label = String(validatingUTF8: __dispatch_queue_get_label(nil))!
        print("sink execute queue: \(label), \($0)") // => [Receive queue 2], 10
    })

The big picture and overview of Combine

Yoshinori Imajo — Mon, 28 Sep 2020 07:43:36 +0000

Introduction

Apple announced the Combine framework at WWDC19. This framework enables reactive programming and declarative coding. This article will give you a quick overview of it and the big picture of Combine.

What is reactive programming?

To help you understand reactive programming, here's an example of how procedural code is not real-time.

var a = 5
let b = 10
let flag = a > b
print(flag) // => false
a = 20
// of course, flag remains unchanged and remains false
print(flag) // => false

The following code shows how reactive programming can be used to deal with values that change in real time.

let a = CurrentValueSubject<Int, Never>(5)
let b = Just(10) // Let 10 be the only element

let publisher = b.combineLatest(a)
  .map { $0 < $1 } // true if b < a

_ = publisher
  .sink { 
    // When the element `a` changes from 10 to 20, 
    // false and true are output one after another.
    print($0)   // => false
                // => true
  } 

a.send(20) // Send 20 as an element of a

n iOS app development, various event notification methods are available to detect changes in value in real-time.
However, the advantage of Combine is that this can be done with an official framework based on ReactiveStreams, which is a generalized reactive programming specification used on other platforms.

Publisher

The concept of notifying an element as an event is called a Publisher. The name Publisher is verbatim from the ReactiveStreams specification and is the equivalent of Observable in RxSwift, which doesn't follow the specification.

Subscriber

The Subscriber is provided as a protocol for handling Publisher events. Rather than using the Subscriber directly, the Subscriber is often used indirectly as a Publisher protocol extension, such as the sink method that handles events. The name Subscriber is also based on the ReactiveStreams specification; RxSwift has a similar concept in Observer.

Publishers

The various types used by operators, such as Maps, are enumerated as Publishers, which are Publisher-compliant and allow the operator to process the stream and convert it to each of the enumerated types.

Subscription

Combine is partially compliant with the ReactiveStreams specification, which is based on the Reactive Manifesto. The Reactive Manifesto is a system design pattern, which refers to the design of all applications, not just mobile apps like iOS. Therefore, it also takes into consideration the fault-tolerant surnames required for server-side applications. The ReactiveStreams specification, which follows the Reactive Manifesto, exists to control notifications between Publisher and Subscriber and to reduce the load on them. That's why. This is called back pressure. Of course, in addition to reducing the load, the role of a Subscription is to provide a method of control in the form of a specification.

But whether or not you create a Subscription depends on whether you create your own Publisher or Publishers.

Subject

The Subject is a highly flexible publisher with the ability to generate events externally.CurrentValueSubject has an initial value.

Subscribers

The Subscribers are provided as a namespace for types that function as Subscribers.

Resource:

Using Back-Pressure By flatMap in Combine framework

Yoshinori Imajo — Sat, 22 Feb 2020 12:36:03 +0000

In the Combine framework, when using flatMap for irreparable processing requests using Web API, it is better to use the maxPublishers argument and use .flatMap(maxPublishers: .max(1)).

For example, by using .flatMap (maxPublishers: .max(1)) as shown below, the Web API POST will not process input events until the result is subscribed.

let cancelable = inputEvents
    .flatMap(maxPublishers: .max(1)) {
        // Example: irreparable processing requests
        createUser(name: $0.email, $0.password)
    }
    .sink {
        ... 
    }

Verification code

Verify the operation with two source codes.

Example without maxPublishers argument for flatMap
- .unlimited by default
Example using .flatMap (maxPublishers: .max(1))

To conclude, .flatMap (maxPublishers: .max(1)) uses a flatMap to fix the number of Publishers created, even if there are new inputs until the result is subscribed. Do not execute.

Example without `maxPublishers` argument in flatMap

Spec
- Input events are (1...3).publisher
- flatMap
  - In the first event, asynchronously delay the number after 1 second and stream the number as a string
  - After the first one, asynchronously stream numbers as strings

import Foundation
import Combine
import PlaygroundSupport

let cancelable = (1...3).publisher
    .flatMap { value -> Future<String, Never> in
        print("🍏flatMap: \(value)")
        if value == 1 {
            return Future<String, Never> { promise in
                let v = value
                // delay the event of the stream created in the first shot.
                DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) {
                    print("🐢after: \(v)")
                    promise(.success("\(v)"))
                }
            }
        } else {
            return Future<String, Never> { promise in
                let v = value
                DispatchQueue.main.async {
                    print("🐰after : \(v)")
                    promise(.success("\(v)"))
                }
            }
        }
    }
    .sink(receiveCompletion: { completion in
        switch completion {
        case .finished:
            print("🍎sink finished:", completion)
        case .failure(let error):
            print("🍎sink failure:", error)
        }
    }) { value in
        print("🍎sink received: \(String(describing: value))")
    }


let page = PlaygroundPage.current
page.needsIndefiniteExecution = true

DispatchQueue.main.asyncAfter(deadline: .now() + 5.0) {
    // Instructs Xcode that the playground page has finished execution.
    print("🕘finished")
    page.finishExecution()
}

This code has the following output:

🍏flatMap: 1
🍏flatMap: 2
🍏flatMap: 3
🐰after : 2
🍎sink received: 2
🐰after : 3
🍎sink received: 3
🐢after: 1
🍎sink received: 1
🍎sink finished: finished
🕘finished

Use asncAfter(deadline: .now() + 1.0) to delay the event of the first stream created. However, events flow one after another and switch to a new stream with flatMap.

Example of using `.flatMap (maxPublishers: .max(1))`

Change the following from the previous code

.flatMap { value -> Future<String, Error> in

↓

.flatMap(maxPublishers: .max(1)) { value -> Future<String, Error> in

This code has the following output:

🍏flatMap: 1
🐢after: 1
🍎sink received: 1
🍏flatMap: 2
🐰after : 2
🍎sink received: 2
🍏flatMap: 3
🐰after : 3
🍎sink received: 3
🍎sink finished: finished
🕘finished

As before, use asncAfter(deadline: .now() + 1.0) to delay the event of the first stream created. It seems that the next event occurs after the delayed event is sink received: 1.

Conclusion

If you do not use the maxPublishers argument in flatMap, event creation does not wait for the end.
- It does not use Back-Pressure.
If you specify max(1) for maxPublishers, event creation waits for completion.
- It is requesting 1 as Back-Pressure.
  - The request repeats with each subscription.
- Even if you specify max(1), the subscription does not end when you create a one-time event.

DEV Community: Yoshinori Imajo

Running Asynchronous Setup Side Effects in `@Test` with Swift Testing

🧩 Introduction

🎯 Goal

💡 Motivation

🧩 Example: Using Realm

🧩 TaskLocal Context

⚙️ Implementing the Trait

🧩 Takeaways

Notes

Building an MCP Server to Use ChatGPT Without API Keys - A Novel Approach Using macOS Shortcuts

Introduction

What I Built

The Problems We're Solving

💰 Cost Issues

🔄 Claude Code Limitations

The Core Innovation: Leveraging macOS Shortcuts

Why This Approach is Revolutionary

How It Works

Key Benefits: Solving Claude Code's Weaknesses

Claude Code's Challenges

Rescue with ChatGPT o3

Real Usage Example

Usage

1. Prerequisites

2. Global Installation

3. Project-Local Setup

How It Works in Practice

Key Learnings

Power of macOS Automation

MCP Protocol Flexibility

Conclusion

Links

Errors in the stream switched using flatMap are not involved upstream in Combine framework.

Using flatMap sample

Using PasshtoughSubject & flatMap sample

Combine.framework Scheduler recap (Diagram)

Diagram to understand about Combine Scheduler

Scheduler Protocol

Reflections on Apple's Document

receive(on:options)

subscribe(on:options)

Comparison with Rx.

The big picture and overview of Combine

Introduction

What is reactive programming?

Publisher

Subscriber

Publishers

Subscription

Subject

Subscribers

Resource:

Using Back-Pressure By flatMap in Combine framework

Verification code

Example without maxPublishers argument in flatMap

Example of using .flatMap (maxPublishers: .max(1))

Conclusion

Example without `maxPublishers` argument in flatMap

Example of using `.flatMap (maxPublishers: .max(1))`