การทดสอบโค้ดแบบอะซิงโครนัส

Network calls and tasks finish later, not instantly. Your tests must wait for the result before asserting, or they check too early. ⏳

The simplest fix is an async test method. Swift lets you await directly, and the runner pauses until the work completes.

Inside an async test you can use await just like real code. The line pauses until your ViewModel finishes loading.

Once the await returns, the data is ready. Now your assertion checks the final state, not an empty one. ✅

If the code can throw, mark the test throws too. Then try await lets errors bubble up and fail the test cleanly.

Hitting a live server makes tests slow and flaky. Inject a mock service that returns fixed data instead.

A mock conforms to the same protocol but returns canned values. Your ViewModel cannot tell the difference, so the logic is tested honestly.

Make your mock throw on demand. Then you can verify the ViewModel sets an error state instead of crashing.

For older callback APIs, use an XCTestExpectation. Fulfill it inside the callback, then wait so the test does not end early.

Pair every expectation with a timeout. If the callback never fires, the test fails fast instead of hanging forever.

When you can, write code with async/await. Tests stay short, linear, and far easier to read than nested callbacks.

How should you wait for async work in a modern XCTest?

You can now test async code: mark tests async, await results, mock the network, and use expectations for callbacks. Reliable every run. 🎉