テスト駆動開発は，設計変更に耐えられるのか

ここまでの流れから，最初に書いたポイントを検証してみることにしましょう。

複雑なものも扱えるのか？

→ 言語の構文解析は複雑。

inputまわりを中心に見ていきましたので，とりわけ複雑というわけではありません。しかし，getchunk()などは，ある要求を満たすために処理を変更すると，他の要求がうまく処理できなくなったりする典型だと考えられます。こういうものは，テストがあることで安心して変更することができます。

より複雑なものについては，次回で取り上げようと思います。

生産性が本当に上がるのか？

→ (これは未検証)

生産性については，数字はないのですが，凡ミスがすぐに見つかるのは助かります。その一方で，原因究明に時間がかかるものもありました(恥ずかしい話ですが，$objを使うべきところでうっかり$thisを使ってしまい，どちらも同じクラスだったので他にエラーが出なかったのです)。

また，インチキコードを書いてテストをいったん通すプロセスは，無駄なので書かずに済ませたいという気持ちが払拭しきれませんでした。

部分でテストしても全体の代わりになるのか？

→ アセンブラとして機能するのかをチェック。

inputbufferからinputlineを含んだテストをするなど，ある程度はユニットをまたいだテストを行っています(inputlineの変更に制約が出るなど，このやり方には悪い点もあります)。また解説はしていませんが，ソースからバイナリが正しく作られることも，同じ方法で自動的に確認しています。

全体のテストが不要になるわけではありませんが，うまく適用できる分野においては，全体のテストが楽になると思います。

テスト可能にするとソースが読みにくくなるのでは？

→ 前回のソースと比較。

テストできるようにしたため，以前と違う書き方になった，という部分は，たしかに存在します。

たとえば，今回はsetparent()を使用しました。inputline()に$parentを渡すように変更すると，今までのテストを多数変更しないといけなくなり，この記事のリストがとても長くなってしまうからです。もしテストの変更がなければ，コンストラクタに$parentを渡していたと思います。これが，テスト駆動開発で，後付けで機能追加したことによる違いの1つということになります。

また，従来は直接エラーメッセージを表示していた部分を，inputlineやinputbufferを通して出力することで，エラーメッセージをテストすることができるようにしています。これはテストに必要だから，というのもありますが，メッセージに行番号などを付加する処理を1箇所にまとめられるという利点もあります。

ですので，少なくとも今回の範囲では，テスト可能にしたためソースが読みにくくなったとは言えないように思います。

最初に構造をしっかり設計しないと，あとから変更できないのでは?

→ 何度も大変更を行った。

これが本題です。今回は，設計をせずに，行きあたりばったりでコードを書いていきました。もちろん，phpでアセンブラというのは，以前に扱った題材ですから，難易度は低くなっていると考えられます。

先ほどのsetparent()のように，変更にあたって気を遣った部分もあります。一方で，コメントを取り除く処理を別のところに移したり，エラーメッセージに行番号を表示する仕組みを何度も変更したりもしています。感覚的には，変更によってソースが管理不能になったり，再利用不能になるということは起きていません。

問題は，テストを書くコストに対して，変更のしやすさという見返りが十分かどうかですが，これについては明確な結論は出せていません。

もっと複雑なプログラム

というわけで，テスト駆動開発の疑問をすべて解消するというわけにはいきませんでした。そこで，このテーマは次回も引き続き取り上げようと思います。ご期待ください。

なお，今回作成したプログラム全体については，以下からダウンロードいただけます。オペランドに式が使えない，includeをサポートしていない，出力がダンプなど，picasm.phpと完全に同じではありませんが，実際に動かしたりテストを実行することができます。

• 今回作成したプログラム