技術・科学

テストファーストでやってみる

投稿日:

仕事でちょっとしたツールを作ることになったので、実験を兼ねてテストファーストでやってみることにした。テストファーストってのはコーディングの前にテストコードを書くってやつだ。

大きな意味では通常の仕事もテストファーストでやっている。コーディングより先の設計の段階でテスト用の仕様書も作っているからだ。テストもきちんと仕様化すればレビューもできるし、コーディングの前に設計上の問題点も見つけやすくなる効果がある。ただ、いかんせんこの方法はテストの自動化に難があるし、自動化しにくいということはコードのリファクタリングもできないということでもあるわけだ。動いたコードは触らないってやつ。これはコードを読みにくくする原因のひとつだ。

テストを仕様化するならテスト用のプログラムを作ることだってできるはずで、最近はそういうテストが書きやすくなるためのJUnitみたいな便利な道具がある。

で、実際にやってみると面白い効果がある。テストがしやすいコードを書くように心がけるようになるのだ。JUnitなどの道具は便利で強力なのだが弱点もある。代表的なのはユーザインタフェースのテストだ。人の操作を前提としている処理は自動化が難しいし、ユーザビリティの観点を評価する必要性を考えれば自動化しないほうがいいということもある。しかしテストの自動化を体験すると後が楽になってくるのでできる限り自動化可能な実装設計をするようになってくる。結果的にクラスなりメソッドなりの結合度が低くなって見通しのよいコードになる。オブジェクト指向のひとつの目標であるクラスの再利用性も高くなる。これは考えてみると当たり前で、テストを書くということは目的コードを使う側に立って実行してみるということにほかならないから、自然に使いやすさに配慮することになるらしい。

もうひとつの効果はテストの内容が具体的になってレビューがしやすいということだ。仕様書レベルのテスト項目というのはレビューしても書き方によってなんとなく正しいような気がしてしまうことがある。記述や実行に個人差が出てテスト自体の品質がばらついてしまう要因になる。

JUnitなどのツールで書くテストは原則として宣言的で明確なものだ。論理で記述するのでそれが正しいかどうかが比較的判断しやすい。コードレビューと同様に仕様書とテストコードを見比べながらウォークスルーすれば効果が大きいだろう。

よくある勘違いは、テストファーストだからといってコードレビューがいらないと思ってしまうことだ。結果が正しければいいと思ってしまいがちだが、テストが万能なわけではない。間違った論理で書かれたプログラムは予想しにくいところで問題を起こす。テストが完璧に全てのケースを想定しているとは限らないということを意識すれば、プログラムに使われているアルゴリズムをきちんと検証しておくことは重要なことだ。テストファーストはあくまでもブラックボックスのテスト。コーディングの段階ではコードレビューとホワイトボックスのテストをきちんとやる必要がある。

テストファーストはまったく新しい考え方ではないが、自動化によって品質向上のスピードアップが期待できる手法なのである。プログラムと、なにより開発者の生活の質の向上に上手に利用したいものである。







書いた人

nyao

nyao

本を書きたい人にITの基礎から学んでもらって、Kindleで著者デビューするまでをサポートします。 ITってよくわからないという人のために勉強会をやっています。 「読書と編集」という屋号でお仕事をしています。

プロフィールを表示 →

-技術・科学

Copyright© NyaoPress 読書と日常 , 2019 All Rights Reserved.