ソフトウェア開発時の、特に機能検証テストを意識した開発手法である TDD（Test-Driven Development : テスト駆動開発）をサンプルを含めて紹介します。　一応、自分の業務で使っている手法であり、ブログという形でアウトプットすることで自分の理解を深めることも目的の１つです。向き不向きあることは理解した上で「こういう開発手法もある」と理解してもらえればと。


【TDD とは？】
文字通りの「テスト中心に進めていく開発」手法です。具体的な例は後述しますが、「開発してからテストを考える」のではなく、「テストありきで開発する」というものです。

ここでの「テスト」とは「開発したソフトウェアプログラムが意図した通りに動くことを確認・検証すること」です。作って終わり、だとバグが多く残っていて、酷い場合はまともに動かないケースもあったりするのですが、そういったことがないように開発作業の一部としてテストを行います。テスト結果の評価方法にもよりますが、許容できないと判断された場合はテスト結果を元にプログラムを修正する必要が生じます。

また多くの場合、自動化できることを意識してテストを準備／実行します。自動化されたテストを CI/CD の環境に組み込むことで「テストに通ったものだけがデプロイされる」ことを実現します。

TDD はフロントエンド（UI）／バックエンドに共通した考えですが、個人的には API を中心としたバックエンド開発に向いている手法だと感じています。理由はテスト自体をアプリケーション開発の一部のように（同じプログラミング言語で）開発でき、テストを作ること自体がプログラミングの一部となり、バージョン管理を含めたソースコード管理がしやすくなるためです。またフロントエンドのテストは同一プログラミング言語では難しかったり、別ツールを使う場合は前述のメリットを享受しにくくなると感じています。　といったこともあり、以下はバックエンド開発を前提とした TDD の説明を行います。

TDD のフレームワークはプログラミング言語ごとに多くあります。後述のサンプルではプログラミング言語環境として一般的な Node.js + Express を使う前提で、テストフレームワークには Mocha(mochajs.org) を、またテスト中のアサーションと呼ばれるメソッドを実行するための Chai(chaijs.com) を併用した例を紹介します。


【TDD をサンプルで実践】
今回、以下のような REST API を開発することになった、とします。社内で多く使われるアプリケーションの機能の一部として「ユーザーの登録、検索、更新、削除」が必要で、これらを実現するような REST API を開発することになりました（認証や認可の話は今回の対象外とします）：

REST API	機能	説明
POST /api/user	ユーザーの登録	POST データを使ってユーザーを新規に登録する。既存ユーザーIDが指定されている場合はエラーとする
GET /api/user/{id}	ユーザーの検索	{id} で示されるIDを持つユーザーを検索する。存在しないIDが指定されている場合はエラーとする
PUT /api/user/{id}	ユーザーの更新	{id} で示されるIDを持つユーザーの情報を POST データを使って更新する。存在しないIDが指定されている場合はエラーとする
DELETE /api/user/{id}	ユーザーの削除	{id} で示されるIDを持つユーザーの情報を削除する。存在しないIDが指定されている場合はエラーとする

ユーザー情報自体は id(string) と name(string) だけを持つものとします：
　例： { id: "001", name: "木村桂" }

例えば POST /api/user を実行して id="100", name="K.Kimura" のユーザーを作成する場合のポストデータは以下のような JSON オブジェクト（の文字列）となります：
　例： { id: "100", name: "K.Kimura" }

同じ id="100" の既存データを name="Kei Kimura" に更新する場合は PUT /api/user/100 の REST API を実行し、以下のようなデータを送信します：
　例： { id: "100", name: "Kei Kimura" }

また全ての REST API の結果は HTTP レスポンス本文内に JSON 文字列で返され、結果の JSON オブジェクトには status 属性が付与されます。この status 値が true の場合は成功、false の場合は何らかのエラーが発生しているものとします：
　成功例： { status: true }
　失敗例： { status: false, error: "エラーの詳細・・" }


これらのような仕様の REST API を実装することが目的であるとします（本ブログでは上２つの GET および POST の API 開発に絞って紹介します）。以下では TDD 手法でこれらの API を開発する様子を紹介します。



【TDD 手法による開発手順】
では上述の REST API を TDD 手法を使って開発してみます。まずは検索機能である GET /api/user/{id} の API を作ってみることにします。

TDD では文字通り "Test-Driven" な開発を行っていくことが特徴です。具体的にはいきなり API の開発に取り掛かるのではなく、最初に「これから作るもののあるべき挙動」を考え、その内容をテストケースとしてプログラムに記述します。まずは GET /api/user/{id} のあるべき挙動を考えることにしましょう。

この API は id を指定して、その指定された id を持つユーザーが登録されていたら status=true でユーザー情報を返す、指定された id を持つユーザーが登録されていなかったらエラー扱いとして status=false でエラー情報を返す、という挙動になるはずです。

例えば既に id="001" というユーザーが登録済みで id="100" というユーザーは登録されていなかった場合のそれぞれの挙動としては、以下の (1), (2) のようになるはずです：
(1) GET /api/user/001 → 成功する（status=true の結果が返る）はず
(2) GET /api/user/100 → 失敗する（status=false の結果が返る）はず

この (1), (2) それぞれの実行とその予想される結果をまずテストとして記述します。　その次に該当の API を開発し、完成したら最初に記述したテストを実行して期待通りの結果になるかどうかを検証します。これが TDD による開発の基本的な流れとなります。


【TDD の準備】
上述の順序に従って実際の開発を行うのですが、その前に各種フレームワークの準備となる作業を紹介しておきます。

TDD による開発をはじめる直前までを実装したプロジェクトをこちらに用意しておきました：
https://github.com/dotnsf/tdd-sample.git


git clone するか、ダウンロード＆展開してプロジェクトを展開します。またこの後すぐにテストが実行できるように必要なライブラリをインストールしておきます：

$ npm install

まずは package.json ファイルの説明をしておきます：

{
    "name": "tdd-sample",
    "version": "0.0.1",
    "scripts": {
        "start": "node app.js",
        "lint": "eslint",
        "test": "mocha --exit **/*.spec.js"
    },
    "dependencies": {
        "body-parser": "1.17.x",
        "cf-deployment-tracker-client": "^0.1.4",
        "express": "4.17.x"
    },
    "repository": {},
    "engines": {
        "node": "8.x"
    },
    "devDependencies": {
        "chai": "^4.2.0",
        "eslint": "^6.8.0",
        "mocha": "^7.0.0",
        "supertest": "^4.0.2"
    }
}

TDD に関わる部分を青字にしておきました。まず dependencies に cf-deployment-tracker-client モジュールを、devDependencies に chai, mocha, supertest モジュールを追加しています。これらを使ってテストを記述および実装します。　また scripts の中で "test": "mocha --exit **/*.spec.js" という要素を記述していますが、これは「**.js というファイル向けのテストが **.spec.js というファイルに記述されていて、これを実行して npm test コマンドでテストする」ことを宣言しています。

実際のソースコードに関わるファイルは app.js と routes/users.js の２つです。app.js には Express を使って HTTP サーバーとして稼働するための最小限のコードが書かれています：

//. app.js
var express = require( 'express' ),
    app = express();
var users = require( './routes/users' );

//. ユーザー関連 API を /api/user 以下にルーティング
app.use( '/api/user', users );

//. ポート番号を決めて起動
var port = process.env.port || 8080;
app.listen( port );
console.log( "server stating on " + port + " ..." );

最小限のコードに青字で書かれた部分が追加されています。青字部分は routes/users.js ファイルを読みこみ、その中に書かれている内容を使って /api/user 以下へのリクエストのルーティングを処理する、という定義になっています。端的に言うと今回テストしようとしているユーザー登録関連 API の中身が routes/users.js に書かれている、という定義をしていることになります。

そしてその routes/users.js ファイルの中身が以下のなります：

//. users.js
var express = require( 'express' ),
    bodyParser = require( 'body-parser' ),
    router = express.Router();

//. ポストデータを JSON で受け取る
router.use( bodyParser.urlencoded( { extended: true } ) );
router.use( bodyParser.json() );

//. 検索 API : GET /api/user/:id
router.get( '/:id', function( req, res ){
});

//. 新規作成 API : POST /api/user
router.post( '/', function( req, res ){
});

module.exports = router;

この中では '/:id' への GET リクエスト（GET /api/user/:id）と '/' への POST リクエスト（POST /api/user）へのハンドラが定義されています（中身がないので、このまま実行してもエラーになります）。本来は PUT や DELETE についてもここで記述するべきですが、本ブログではこの２つまでを TDD で開発する様子を紹介するので、この２つを記載しておきました。続きを自分で作る場合は是非追加してチャレンジしてみてください。


【テストケースの実装】
では実際に TDD を使って開発作業の続きを行っていきます。API そのものは routes/users.js の中身（route.get ハンドラと route.post ハンドラの中身）を書いて実装していくことになるのですが、前述のように TDD ではテストケースを先に定義します。上記の緑で書いた (1), (2) のテストケースを先に作って、その後で routes/users.js を作っていく、という順序になります。

ではまずはテストケースを用意します。users.js のテストケースは users.spec.js に作る、という宣言をしているので、routes/users.spec.js というファイルを以下の内容で新規に作成します：

//. users.spec.js
var request = require( 'supertest' ),
    chai = require( 'chai' ),
    app = require( '../app' );

chai.should();

/* (1) のテスト */
describe( 'GET /api/user/001', function(){
  it( 'should return user object', async function(){
    var result = await request( app ).get( '/api/user/001' );
    result.statusCode.should.equal( 200 );
    result.body.status.should.equal( true );
  });
});

/* (2) のテスト */
describe( 'GET /api/user/100', function(){
  it( 'should return 404 for non-existing user', async function(){
    var result = await request( app ).get( '/api/user/100' );
    result.statusCode.should.equal( 404 );
    result.body.status.should.equal( false );
  });
});

特に緑で記述した部分で実際にテストを行っています。ここでの記述方法についての詳細は別途参照いただきたいのですが、実際にテストしたい内容と照らし合わせてなんとなく理解できるのではないかと思っています。(1) のテストでは（id="001" というユーザーが存在している前提で） GET /api/user/001 という API を実行し、その結果はステータスコードが 200 で、実行結果の JSON に { status: true, .. } という要素が含まれていることを確認してテスト成功とみなす、という内容を記述しています。　また (2) のテストでは（id="100" というユーザーが存在していない前提で） GET /api/user/100 という API を実行し、その結果はステータスコードが 404 で、実行結果の JSON に { status: false, .. } という要素が含まれていることを確認してテスト成功とみなす、としています。GET /api/user/{id} の API が正しく動いていればこうなるはず、という仕様を JavaScript で記述した例だと思ってください。

このテストケースを用意した上で実際の API を開発します。実際の API は routes/users.js ファイルの router.get( '/:id', ... で始まるハンドラーの中身として記述していきます。今回は以下のような内容の routes/users.js にしました（元のファイルに追加した部分を赤で記載しています）：

//. users.js
var express = require( 'express' ),
    bodyParser = require( 'body-parser' ),
    router = express.Router();

//. ポストデータを JSON で受け取る
router.use( bodyParser.urlencoded( { extended: true } ) );
router.use( bodyParser.json() );

//. 本来は RDB などに格納するべき情報だが、この例では配列変数を使って簡易的に保存する
var users = [
  { id: "001", name: "K.Kimura" },
  { id: "002", name: "dotnsf" }
];

//. 検索 : GET /api/user/:id
router.get( '/:id', function( req, res ){
  var id = req.params.id;
  if( id ){
    var user = findOne( id );
    if( !user ){
      return res.status( 404 ).json( { status: false, error: 'user with id ' + id + ' not existed.' } );
    }else{
      return res.json( { status: true, user: user } );
    }
  }else{
    return res.status( 404 ).json( { status: false, error: 'parameter id required.' } );
  }
});

//. 新規作成 : POST /api/user
router.post( '/', function( req, res ){
});

//. id からユーザーを検索して返す
function findOne( id ){
  var u = null; //. 見つからない場合は null を返す
  users.forEach( function( user ){
    if( user.id == id ){
      u = user;
    }
  });

  return u;
}

module.exports = router;

まずこの API で扱うユーザー情報ですが、本来はデータベース等に格納したり、そこから取り出して取得するものだと理解しています。もちろん実際にそのように記述してもいいのですが、今回は TDD の解説を主目的としており、直接関係ない部分でコードを複雑化することは目的ではないため、この部分を簡易的に実装することにしました。具体的には上述のようにコード内に users という配列変数を用意し、この変数の中にユーザー情報が格納されていて、必要に応じて追加・更新・削除ができるような形で API を実装しています（この仕様によりアプリケーションを再起動するたびに中身は初期化されます）。またテストは id="001" のユーザーは存在していて、id="100" のユーザーは存在していない前提で実施されるため、id="001" のユーザーははじめから作っておくことにしました（同じ理由で id="100" のユーザーは作らないようにしてください）。

その上で router.get( '/:id', ... で始まるハンドラーの中身を API の実装として記述しています。まず URL の一部として指定される id の値を取得し、その値を id として持つユーザーを（findOne 関数で）検索し、null でないオブジェクトが返ってきたら、その結果を実行結果として { status: true, user: （実行結果） } の形で返すようにしています（特に指定していない時のステータスコードは 200 です）。指定した id のユーザーが存在しなかったり、id が指定されていなかった場合はステータスコード 404 を返しつつ、{ status: false, error: （エラーの原因） } という結果を返すようにしました。これで GET /api/user/{id} の実装例としては最低限動くものが作れました。

この後は実際にテストを実行するのですが、その前に app.js にも一箇所変更の必要があります。テスト時にはアプリケーション本体である app.js が実行された上でテストケースを確認することになります。この作業を効率的に行うために app.js をテストケースから呼び出して実行できるように最後に数行コードを追加します（赤字部分を追加）：

//. app.js
var express = require( 'express' ),
    app = express();
var users = require( './routes/users' );

//. ユーザー関連 API を /api/user 以下にルーティング
app.use( '/api/user', users );

//. ポート番号を決めて起動
var port = process.env.port || 8080;
app.listen( port );
console.log( "server stating on " + port + " ..." );

//. テスト用に app 全体をエクスポート
require('cf-deployment-tracker-client').track();
module.exports = app;

【テストの実行】
ではテストケースと API 両方の準備ができたので、実際にテストを実行してみます。package.json 内にテスト用の scripts が用意されているので "npm test" コマンドを実行することで *.spec.js というファイルを見つけて *.js のテストを行います（青字部分がテスト結果です。またこの段階のプロジェクトでは routes/users.spec.js というファイルを見つけて、routes/users.js ファイルのテストだけが行われますが、ファイルが増えても同様のコマンドでまとめてテストできます）：

$ npm test

    :

server stating on 8080 ...


  GET /api/user/001
    ✓ should return user object

  GET /api/user/100
    ✓ should return 404 for non-existing user


  2 passing (53ms)

この結果にはテストファイル（routes/users.spec.js）内の describe 関数で書かれた実行内容と、it 関数で書かれた期待結果が２つずつ表示され（つまり２つのテストが実施され）、どちらも pass したことを意味しています。つまり用意したテストに耐えうる API が開発できた、ということになります。

ちなみにわざとエラーを起こすようなテストケース（実在する id="002" のユーザーが見つからない想定）を用意して実行すると次のような結果になり、テストに通らなかったことがわかります：

npm test

    :

server stating on 8080 ...


  GET /api/user/001
    ✓ should return user object (40ms)

  GET /api/user/002
    1) should return 404 for non-existing user


  1 passing (82ms)
  1 failing

  1) GET /api/user/002
       should return 404 for non-existing user:

      AssertionError: expected 200 to equal 404
      + expected - actual

      -200
      +404

      at Context. (routes/users.spec.js:21:30)
      at 
      at process._tickCallback (internal/process/next_tick.js:189:7)



npm ERR! Test failed.  See above for more details.

【API の拡張とテストの再実行】
一応、ここまでの手順で最小限度の TDD が体験できているのですが、少しだけプラスアルファの要素を含めてみます。先程は GET （検索）の API を作ったので、続いて POST （新規作成）の API も TDD で開発してみます。

GET の時と同様にして、まずは POST API の仕様を考え、その仕様をもとにテストケースを考えます。先程作成済みの GET API とそのテストケースを使って、今回は以下のような挙動になるべきである、と考えたとします：
（(2) で id="100" のユーザーが存在していないことを確認しているので、ここに続けて）
(3) POST /api/user/100 → 成功する（status=true の結果が返る）はず
(4) GET /api/user/100 → 成功する（status=true の結果が返る）はず

つまり (2) で id="100" のユーザーが存在していないことを確認した上で、(3) で id="100" のユーザーを作成し、(4) で (2) と全く同じテストを実行して今度はユーザーが見つかる、という挙動になることをテストで確認することにします。

この仕様のため、routes/users.spec.js を以下のように変更します（書き加えた部分を赤字で示しています）：

//. users.spec.js
var request = require( 'supertest' ),
    chai = require( 'chai' ),
    app = require( '../app' );

chai.should();

/* (1) のテスト */
describe( 'GET /api/user/001', function(){
  it( 'should return user object', async function(){
    var result = await request( app ).get( '/api/user/001' );
    result.statusCode.should.equal( 200 );
    result.body.status.should.equal( true );
  });
});

/* (2) のテスト */
describe( 'GET /api/user/100', function(){
  it( 'should return 404 for non-existing user', async function(){
    var result = await request( app ).get( '/api/user/100' );
    result.statusCode.should.equal( 404 );
    result.body.status.should.equal( false );
  });
});

/* (3) のテスト */
describe( 'POST /api/user', function(){
  it( 'should create user object', async function(){
    var result = await request( app ).post( '/api/user' )
      .send( { id: '100', name: 'Linux' } );
    result.statusCode.should.equal( 200 );
    result.body.status.should.equal( true );
  });
});

/* (4) のテスト（(2) と全く同じ内容で結果が異なるはず） */
describe( 'GET /api/user/100', function(){
  it( 'should return user object', async function(){
    var result = await request( app ).get( '/api/user/100' );
    result.statusCode.should.equal( 200 );
    result.body.status.should.equal( true );
  });
});

このテストケースを満たすように POST の API を開発していきます（場合によっては GET API にも手を加えていきます）。今回はポストされたデータから id を取り出し、既存ユーザーが存在していないことを確認した上で users 変数に push するだけの実装にしてみました：

//. users.js
var express = require( 'express' ),
    bodyParser = require( 'body-parser' ),
    router = express.Router();

//. ポストデータを JSON で受け取る
router.use( bodyParser.urlencoded( { extended: true } ) );
router.use( bodyParser.json() );

//. 本来は RDB などに格納するべき情報だが、この例では配列変数を使って簡易的に保存する
var users = [
  { id: "001", name: "K.Kimura" },
  { id: "002", name: "dotnsf" }
];

//. 検索 : GET /api/user/:id
router.get( '/:id', function( req, res ){
  var id = req.params.id;
  if( id ){
    var user = findOne( id );
    if( !user ){
      return res.status( 404 ).json( { status: false, error: 'user with id ' + id + ' not existed.' } );
    }else{
      return res.json( { status: true, user: user } );
    }
  }else{
    return res.status( 404 ).json( { status: false, error: 'parameter id required.' } );
  }
});

//. 新規作成 : POST /api/user
router.post( '/', function( req, res ){
  var id = req.body.id;
  if( id ){
    var user = findOne( id );
    if( user ){
      return res.status( 400 ).json( { status: false, error: 'user with id ' + id + ' already existed.' } );
    }else{
      users.push( req.body );
      return res.json( { status: true } );
    }
  }else{
    return res.status( 400 ).json( { status: false, error: 'parameter id required.' } );
  }
});

//. id からユーザーを検索して返す
function findOne( id ){
  var u = null; //. 見つからない場合は null を返す
  users.forEach( function( user ){
    if( user.id == id ){
      u = user;
    }
  });

  return u;
}

module.exports = router;

そして開発したコードをテストし、全てのテストコードが期待通りに動くことを確認します：

$ npm test

    :

server stating on 8080 ...


  GET /api/user/001
    ✓ should return user object (49ms)

  GET /api/user/100
    ✓ should return 404 for non-existing user

  POST /api/user
    ✓ should create user object (120ms)

  GET /api/user/100
    ✓ should return user object


  4 passing (203ms)

動きました！これで POST の API も開発できました。　以降、同様にして PUT（更新）や DELETE（削除）の API も、まず仕様を決めて、その仕様が満たすべきテストケースを考えて routes/users.spec.js に記述してから routes/users.js で API を開発してテスト、、、を繰り返す形で開発を進めていきます。これが TDD の典型的な開発手順となります。


【TDD への印象】
上でも少し触れていますが、この TDD という開発手法に対する自分の印象を記載しておきます。

まず開発体制が開発者とテスターとにきっちりと別れていないような場合（開発者＝テスターの場合）であっても、この方法であれば、ある程度は客観的なテストが成立すると考えています。開発したものに対して、開発者がテストケースを考えるとどうしても漏れが出てしまったり、そもそも同一者によるテストを信用していいかどうかの問題も出てきます。その点 TDD では開発する前にテストケースを考えることで、同一者であってもある程度客観性が担保されたテストが可能になります。

また開発者とテスターが別れているケースでもメリットはあります。テスターを「開発トレーニングの一環」として考える場合、テスターもプログラミングによってテストを記述することになり、開発環境の構築や開発、デバッグの経験を積むことができるようになります。

一方で、特にこの手法の場合は REST API 開発のテストには向いていると思うのですが、フロントエンド側のテストを行うことが難しくなります。フロントエンドの HTML を取得して、その中身を解析して正誤を判断する、ことができないことはないと思いますが、そこまでのテストケースを作ることが大きな開発内容となってしまい、テストケースそのものが正しく作られているかどうかの問題も出てきてしまうと考えました。どうしてもバックエンド（REST API）向けのテストだと感じています。

タグ ：

#tdd

#test

#nodejs

#express

#mocha

#chai