先生と生徒の会話形式で理解しよう

生徒

「COBOLでプログラムを書きましたが、これが本当に正しく動くか確かめるための『テストコード』ってどうやって作ればいいですか？」

先生

「テストコードは、本番のプログラムが期待通りに動くか自動でチェックするための大切な道具です。実は、テスト用プログラムの作り方や名前の付け方にも標準的なルールがあるんですよ。」

生徒

「自分だけがわかる適当な名前をつけていました。標準化するとどんないいことがあるんですか？」

先生

「誰が見ても、それがどのプログラムをテストしているのか一目でわかるようになります。それでは、テストコードの標準化と命名例を詳しく解説しましょう！」

1. テストコードとは？品質を支える自動点検の仕組み

プログラミングの世界でいうテストコードとは、作成したメインのプログラムに対して、「正しいデータを入れたら正しい結果が返ってくるか」を自動で確認するための補助的なプログラムのことです。パソコンを触ったことがない方でも、工場の検品作業をイメージすれば分かりやすいでしょう。

例えば、お菓子を作る機械（本番プログラム）を作ったとします。その機械がちゃんと動くか、実際に材料を入れてみて、形や重さを量る検査専用の機械（テストコード）を隣に置くようなものです。手作業で何度も確認するのは大変ですが、テストコードがあれば、何度でもボタン一つで「合格」か「不合格」かを判定できます。

COBOLは銀行や公共機関など、一円のミスも許されないシステムで使われることが多い言語です。そのため、作成したプログラムが完璧であることを証明するために、このテストコードを標準的な手順で作ることが非常に重視されています。テストコード自体が整理されていることで、システムの信頼性が格段に向上するのです。

2. テストコードを標準化する理由とメリット

標準化（ひょうじゅんか）とは、誰が作っても同じような形、同じようなルールになるように決めておくことです。テストコードを標準化しないと、Ａさんが作ったテストプログラムは使い方が分かりやすく、Ｂさんが作ったものは動かし方が分からない、といったバラつきが出てしまいます。

標準化のメリットは主に三つあります。一つ目は「誰でもテストを実行できること」。二つ目は「後から修正がしやすいこと」。そして三つ目は「テストの漏れ（確認し忘れ）を防げること」です。決まった型に従ってテストコードを書くことで、重要な計算ルートをすべて確認したかどうかが一目瞭然になります。

また、大規模な開発現場では、自分が書いたプログラムのテストを別の人が担当することもあります。そんな時、標準化されたルールがあれば、説明書がなくてもスムーズに作業を引き継ぐことができます。チーム全体で同じ「物差し」を持つことが、品質管理の第一歩なのです。

3. テスト用プログラムの命名規則と具体例

テストコードを作る際、最も重要なルールの一つが命名規則（めいめいきそく）です。これは名前の付け方のルールのことです。テストプログラムの名前を見ただけで、どのプログラムを、どのような目的でテストしているのかが分かるようにします。

一般的なCOBOLの開発現場では、本番プログラムの名前に特定の記号を付け加える方法が採用されます。

本番プログラム名： SALES01（売上計算）
テスト用プログラム名： T-SALES01 または SALES01T

頭に「T（Testの略）」を付けたり、お尻に「T」を付けたりすることで、本番用とテスト用が混ざらないように管理します。また、異常なデータを入れるテストなら「SALES01-ERR」のように、目的を後ろに付け足すこともあります。パソコン初心者の方は、フォルダの名前に「2026年分_家計簿」と付けるように、中身が想像できる名前を付ける感覚を大切にしてください。

4. ユニットテスト（単体テスト）コードの書き方

COBOLで最小単位の処理を確認するテストをユニットテスト（または単体テスト）と呼びます。一つの機能だけを切り出して、正しく動くかを確認します。ここでは、メインのプログラムから一部の計算処理を呼び出し、その結果が正しいかを表示するシンプルなテストコードの例を見てみましょう。

以下のコードは、数値を二倍にする処理が正しく動くかを確認するためのテスト用プログラムです。本番の処理を呼び出して、戻ってきた値が自分の予想（期待値）と合っているかをチェックしています。このように「比べる」作業を自動化するのがテストコードの基本です。


* 数値計算処理をテストするプログラム例
IDENTIFICATION DIVISION.
PROGRAM-ID. T-CALC01.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 TEST-INPUT    PIC 9(03) VALUE 100.
01 TEST-OUTPUT   PIC 9(03).
01 EXPECT-VALUE  PIC 9(03) VALUE 200.
PROCEDURE DIVISION.
    * 本番の計算部品を呼び出す
    CALL "CALC-SUB" USING TEST-INPUT TEST-OUTPUT.
    * 結果が正しいか判定する
    IF TEST-OUTPUT = EXPECT-VALUE
        DISPLAY "テスト成功：結果は 200 でした"
    ELSE
        DISPLAY "テスト失敗：期待値と異なります"
    END-IF.
    STOP RUN.

5. テストデータの準備と外部ファイル連携の標準

テストコードを動かすためには、テストに使うデータ（テストデータ）が必要です。プログラムの中に直接データを書く方法もありますが、大量のパターンを確認する場合は、外部のファイルからデータを読み込むのが標準的な手順です。これにより、プログラムを書き換えずに、データの入れ替えだけで様々なテストが可能になります。

標準化されたテスト環境では、テストデータのファイル名も規則的に決められます。例えば「プログラム名.IN.TEST01」といった具合です。このように場所と名前を固定することで、誰でも同じ条件でテストを再現できるようになります。再現性（さいげんせい）とは、何度やっても同じ結果になることであり、システム開発において非常に重要な概念です。

難しい単語が出てきましたが、「外部ファイル連携」とは、プログラムの外に置いてあるメモ帳のようなものから情報を読み取ることだと考えてください。テストコード自体は「読み取り機」として作り、中身のデータは「テストケース」として別に管理するのがプロのやり方です。

6. 期待値との比較と合否判定のロジック

テストコードの中で最も大切な処理が、実行結果と期待値（きたいち）の比較です。期待値とは、「こうなるはずだ」という正解の数字や文字のことです。この比較を人間の目で行うと見落としが発生しますが、プログラムにやらせれば正確無比です。

標準的なテストコードでは、単に「合っているか」だけでなく、間違っていた場合に「何が届いたのか」を表示するように作ります。これにより、不具合の原因（バグ）を素早く見つけることができます。以下のコード例では、文字の変換が正しく行われたかを判定するロジックを示しています。初心者の方も、どのように比較が行われているか注目してみてください。


* 文字変換処理のテストプログラム例
IDENTIFICATION DIVISION.
PROGRAM-ID. T-CONV01.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 IN-NAME      PIC X(10) VALUE "suzuki".
01 OUT-NAME     PIC X(10).
01 EXPECT-NAME  PIC X(10) VALUE "SUZUKI".
PROCEDURE DIVISION.
    CALL "UPPER-CASE-PROG" USING IN-NAME OUT-NAME.
    IF OUT-NAME = EXPECT-NAME
        DISPLAY "OK: 変換成功"
    ELSE
        DISPLAY "NG: 変換失敗 期待値=" EXPECT-NAME " 結果=" OUT-NAME
    END-IF.
    STOP RUN.

7. スタブ（代役）を使った複雑なテストの簡略化

テストしたいプログラムが、まだ出来上がっていない他のプログラムや巨大なデータベースを必要としている場合、テストが進まなくなってしまいます。そんな時に使うのがスタブと呼ばれる「身代わり（代役）」のプログラムです。これもテストコードの標準化には欠かせない要素です。

スタブは、本物のふりをして「常に決まった値」を返してくれる単純な部品です。例えば、銀行の残高を取得する複雑な処理の代わりに、「いつでも残高100万円」と答えるスタブを用意します。そうすることで、残高を受け取った後の計算処理が正しいかどうかを、本物のシステムがなくても先にテストできるのです。

専門用語で難しく聞こえますが、ドラマの撮影で主役が来る前に立ち位置を確認する「代役の俳優さん」のようなものだと思ってください。スタブを上手に使いこなすことで、開発の早い段階からテストを積み重ねることができ、最終的なミスの削減に繋がります。


* データベースの代わりに一定の値を返すスタブ例
IDENTIFICATION DIVISION.
PROGRAM-ID. DB-STUB.
LINKAGE SECTION.
01 L-ACCOUNT-ID PIC 9(05).
01 L-BALANCE    PIC 9(09).
PROCEDURE DIVISION USING L-ACCOUNT-ID L-BALANCE.
    * どんなIDが来ても、テスト用に1,000,000円を返す
    MOVE 1000000 TO L-BALANCE.
    EXIT PROGRAM.

8. テスト実行結果のログ出力とエビデンス管理

テストを行った証拠のことを、IT業界ではエビデンスと呼びます。テストコードを動かした後は、必ずその実行結果をファイルや画面に出力し、記録として残さなければなりません。標準化の手順では、このログ（記録）のフォーマットも統一されます。

「いつ、どのテストコードを動かし、どのデータを使って、結果がどうだったか」を時系列で記録します。このエビデンスがあることで、後から「本当にテストしたの？」と疑われたときに、自信を持って「はい、ここに証拠があります」と言えるようになります。また、将来システムを改造したときに、以前のテスト結果と比較することで、新しい不具合が混入していないかを確認することもできます。

以下の実行結果の例は、複数のテストを連続で行った時のログのイメージです。ひと目で状況がわかるように工夫して出力することが、管理しやすいテストコードの条件です。パソコン初心者の方も、まずは自分のやった作業の「足跡」を残す習慣をつけましょう。


    --- TEST START: 2026-03-10 10:00 ---
    TEST-CASE 01 (NORMAL DATA): SUCCESS
    TEST-CASE 02 (MAX VALUE  ): SUCCESS
    TEST-CASE 03 (EMPTY DATA ): SUCCESS
    --- ALL TESTS COMPLETED: 3 PASS, 0 FAIL ---

9. 継続的なテストとリグレッションテストの概念

プログラムは一度作って終わりではありません。法改正や業務の変更に合わせて、何度も修正されます。そのたびに、昔作ったテストコードをもう一度動かして、壊れていないかを確認することをリグレッションテスト（回帰テスト）と呼びます。一度作ったテストコードは、捨てずに大切に保管しておくのが標準的な運用です。

標準化されたテストコードがあれば、修正を加えた後にすべてのテストを再実行する「全件テスト」が容易になります。もしテストコードを適当に作っていたら、修正のたびにテストを作り直すことになり、膨大な時間がかかってしまいます。過去の遺産を活かし、安全にシステムを成長させていくための知恵が、テストコードの標準化には詰まっています。

プログラミング未経験の方は、まずは「書いたコードが動くか確かめる専用のコードを書く」という、二重の手間に感じるかもしれません。しかし、この丁寧な積み重ねこそが、何十年も動き続ける巨大なシステムを支える土台なのです。ルールを守り、美しいテストコードを書くエンジニアを目指して、一歩ずつ進んでいきましょう。