画面は開くのに、ボタンを押した後の点数が正しいのか確かめられません。 今週は計算や状態変更を画面から分け、テスト対象にSwift Testingのテストを書いて実行します。ロジックの合格と画面全体の確認は別に行います。

初めてSwiftUIの練習プロジェクトに単体テストを加える学生は、テスト対象の準備から順に進められます。 アプリは動くものの、入力処理や状態変更の間違いが心配な人にも役立ちます。 学校のMacやリモートMacで課題に取り組む人は、最後の環境確認と結果の保存方法も参考にしてください。

01

Swift TestingでSwiftUIプロジェクトのテスト対象を決める

テストで最初に確かめるのは、画面の見た目ではなく、入力に対してコードが正しい結果を返すかです。たとえば点数表示が画面に出ても、加点の処理が誤っていれば、表示だけの確認では見逃す可能性があります。

単体テストは、機能を小さく切り分けて確かめる「作業ごとの採点」に似ています。一方、画面をタップしたときの反応や表示位置の確認は、アプリを実際に動かして行う別の作業です。Swift Testingの役割については、フレームワークの概要も確認できます。

確かめるもの 向いている方法 合格で分かること
点数計算、入力チェック、状態変更 Swift Testingの単体テスト 決めた入力に対するロジックの結果
ボタンの反応、画面遷移、表示 シミュレーターや実機での操作 画面上で操作が期待どおり進むか
課題の提出条件 授業で指定された方法 指定環境や手順を含む課題要件

Swift TestingでSwiftUIの最初の単体テストを書くには、何から始めますか？ 点数の加算など、入力と結果を説明しやすい処理を1つ選びます。AppleのSwift Testingを使ってスコアアプリに機能を追加するチュートリアルも、処理を確かめる流れを学ぶ参考になります。

02

画面の計算を呼び出せる形にする

既存のViewに計算が混ざっている場合は、まず計算部分を関数や型に分けます。画面のレイアウトと点数の更新を別々に扱えるようにすると、テストから計算だけを呼び出せます。

たとえば、点数を加算し、減点で負の値にならないようにする処理を次のようにまとめます。

struct ScoreCounter {
    private(set) var score = 0

    mutating func addPoint() {
        score += 1
    }

    mutating func subtractPoint() {
        if score > 0 {
            score -= 1
        }
    }
}

ここでの確認手順は「与える条件」「実行する操作」「期待する結果」の順です。通常の加算だけでなく、点数が0のときに減点しても負の値にならないかを境界条件として考えます。境界条件とは、空欄や最小値など、間違いが出やすい端の状態を確かめるための条件です。

03

Xcodeのテスト対象にファイルを置く

テスト対象とは、テストコードを置くプロジェクト内の独立した領域です。アプリ本体のファイルと同じ場所に見えていても、テスト対象に含まれていなければ実行時に見つからないことがあります。

Swift Testingのテストファイルは、どのテスト対象に置きますか？ アプリ本体ではなく、プロジェクトに用意されたテスト用の対象に所属させます。新規プロジェクトでは作成時のテスト構成を確認し、既存プロジェクトではテスト用対象の有無とファイルの所属先を確認してください。Xcodeプロジェクトにテストを追加する公式手順と、プロジェクトに新しい対象を構成する説明が確認先になります。

Xcode 27を使う場合も、画面上の項目名や対応環境は、手元のバージョンとプロジェクト設定に照らして確認します。実行に必要なmacOSの条件は、Xcodeのシステム要件で確認できます。

04

テスト関数を作成して結果を読む

テスト用ファイルにSwift Testingを読み込み、テスト関数の中で入力の準備、処理の呼び出し、結果の確認を行います。期待する結果を表す「断言」は、採点でいう正解条件です。Swift Testingでは#expectを使って条件を確認できます。詳しくは期待条件の公式説明を参照してください。

import Testing
@testable import MyApp

struct ScoreCounterTests {
    @Test
    func addingPointIncreasesScore() {
        var counter = ScoreCounter()

        counter.addPoint()

        #expect(counter.score == 1)
    }

    @Test
    func subtractingAtZeroDoesNotCreateNegativeScore() {
        var counter = ScoreCounter()

        counter.subtractPoint()

        #expect(counter.score == 0)
    }
}

MyAppはアプリ側のモジュール名に合わせます。また、ScoreCounterがテスト側から参照できる場所にあることを確認してください。テストコードの形は、AppleのSwift Testingチュートリアルと照らし合わせられます。

Xcodeからテストを開始したら、結果一覧で成功または失敗を確認します。成功なら設定した条件を満たしたという意味で、画面全体が正しいという意味ではありません。失敗した場合は、入力、実行した処理、期待値の順に見直します。テストの実行と結果の読み方では、結果の確認方法が説明されています。

05

テストが見つからないときの切り分け

アプリは実行できるのに、テストが表示されないのはなぜですか？ まず、ファイルがテスト用対象に所属しているかを確認します。次に、Swift Testingのインポートとテスト関数の宣言を確認し、Xcodeのテスト一覧に関数が現れるかを見ます。アプリの起動成功だけでは、テスト対象の設定が正しいとは限りません。

テストが表示されても失敗する場合は、原因を分けて考えます。テスト対象そのものが起動できないなら対象の構成を見直し、テストは動くが結果が違うなら入力値と期待値を照合します。それらが一致しているのに失敗する場合は、実際のロジックを確認してください。根拠なくキャッシュ削除やツールの再インストールに進むより、結果に沿って調べるほうが原因を絞れます。

06

課題の提出前にロジックと画面を別々に確認する

単体テストが通った後も、シミュレーターで画面を確認する必要はありますか？ 必要です。テストが確認したのは用意した条件でのロジックなので、画面上のタップ、表示、画面遷移までは保証しません。アプリをシミュレーターで操作し、授業で実機確認や提出形式が指定されている場合は、その条件も別に満たします。

提出前は、まず通常の入力で結果が合うか、次に空欄や最小値など代表的な境界条件で破綻しないかをテストします。その後、アプリを起動して画面操作を確認し、課題で指定された環境と実行結果を記録します。「ロジックのテストが通った」「シミュレーターで動いた」「授業の受け入れ条件を満たした」は、それぞれ別の確認結果です。

手元にMacがなく、Windows上の仮想環境だけで進める場合は、Xcodeを使うためのmacOS環境や互換性の確認が課題になります。長期の開発で物理接続が必要なら自分のMacが向きますが、購入前にSwiftUIとXcodeの課題を試したい場合、NodeMiniのリモートMac環境の案内を選択肢として確認できます。利用できるMacの案内や申し込み方法を比べる際は、Mac miniの注文案内も参照できます。

手元のWindows環境だけではmacOS専用ツールをそのまま使えず、仮想環境では設定や対応状況の確認が増えるため、学習期間に限ってMacを利用する方法も比較してみてください。長期の安定した開発や物理接続が必要な場合は、自分のMacを使うほうが適しています。