テストコードの要らないTDD(テスト駆動開発)風味なプログラマ仕事術

はじめに

こんばんわ、炭山水です。もともとこの記事書きたくてブログ立てたので一気に投稿しちゃいます。
これから書くことは、テストの教科書を読んでまとめたり、何かのベストプラクティスとしてまとまっている話ではなく、ダメエンジニアからどうにかこうにか現場でもまれた僕が、痛い目を見ながら反省点として生まれたものです。
あんまりきれいなやり方ではないので、つよいエンジニアさんは「こんな考えもあるんだなぁ」くらいのお手柔らかな感じでご覧いただけると幸いです。

この記事をかいたきっかけ

この辺のつぶやきをきっかけに取り留めなくtweetしてたら思いのほか筆がノッてきたのでそのうちまとめようかなと思った次第です。良かったらTweetも見てやってください。

誰に向けて書いたか

Tweetしてる時は特に気にしてなかったですが、こんな方対象になるのかなと思います。

• 最近コード書く仕事について、設計書読みながらプログラミングするようになった方
• テスト駆動開発(以下TDD)に興味を持ち始めたけど、結局何がメリットかよくわからないという方
• コードレビューしてる工数がとれずに、なるべく低コストにメンバーの仕様理解度をチェックしたいリーダー
• IT業界入りたてでテスターにアサインされたけど、テストつまんねぇ！って思ってる方

先にオチ

テストコード要らないとは書きましたけど、テストコードあってもいいと思います。むしろ僕は自動テスト推奨派です。
でも、TDDの概念とツールの使い方を同時に語るとごっちゃになると思いますので具体的な言語でのテストコードの書き方みたいなものの言及は避け、そもそもどういう段取りで仕事したらええん？みたいな話をします。

テストについてもろもろの前提のお話

TDDを掲げておきながらちょっと回り道して恐縮ですが、テストの分類について僕の考えについて書いておきます。

テストをする人による分類

現場からの実感ですが、テストと一口に言っても、
・開発者が自分の想定通り実装できてるか確認する自己チェック＋その報告方法
・品質管理部門としてのテスト
・受け入れテスト
でずいぶんノウハウも観点も違います。単体だの結合だのはここでは言及しません。

基本僕は開発者です。「開発者が自分の想定通り実装できてるか確認する自己チェック＋その報告方法」の話をここではメインにします。

ホワイトボックステストとブラックボックステスト

先に行ってしまうと、僕なりの優先度としては

ブラックボックステスト ＞ ホワイトボックステスト

です。
全部の処理を通すとか、カバレッジを100%にするとかそりゃあやるに越したことはないですが、そもそも間違った仕様理解から書かれたコードの分岐を全部なぞったところで何の意味もありません。
まずはちゃんと仕様通りに動くものをつくり、仕様通りに動いたかテストしましょーねと思ってます。

というわけで、ちゃんとブラックボックステストに関する話をここではメインとします。

単体テストとか結合テストとか

よく聞く単語だし、TDDではだいたい単体テストの話をしていますが、これ言葉の定義が職場によって違いすぎるし、ブラックボックステスト優先主義から考えたらぶっちゃけどっちでもいいです。
なんとなくざっくりと「任された範囲ひと固まりがあなたにとっての単体テストです」くらいの暴論で行きたいと思います。

TDD風味な開発の進め方

とりあえずやってみる

貴方が担当にアサインされたら仕様書なり指示書なり設計書なり、「ここに書いたことをプログラムで実現してね」っていう資料を渡されると思います。メモとかRedmineにめっちゃ書かれた打ち合わせ内容とカかもしれません。名前ブレ面倒なので、「仕様書」に統一します。

え？内容があいまい？読むだけじゃよくわからん？
大丈夫です。往々にしてそんなもんです。そんな事態でもきっちり詰めるための手法でもあるのでさっさと先に進めましょう。ただ待ってるよりアクションとった方がまだマシってもんです。

さて、何はともあれ仕様書を読みながら、
・仕様書に書いてある機能のすべての操作について、結果を書き起こす
・仕様書に書いてあるすべての結果に対して、必要な操作を書き起こす
これを地道にやってみてください。後述しますが、書き起こせないことがあるのは想定済みです。とにかく書き起こせないところは何がわからないかメモして先に進んでください。

道具はmarkdownでもExcelでも何でもいいです。古の手法かもしれませんが僕はExcelを推します。俯瞰しやすいからね。
さらに言うと、ディシジョンテーブルがおすすめです。ディシジョンテーブルの説明し始めると長くなるのでこちらのサイトに説明を頼ります。

デシジョンテーブルの解説：ソフトウェアテスト・テスト技法に関する情報サイト

ただし、「項目Aに値を入れ、項目Cの結果が正しいことを確認する」みたいなボケたテスト項目は論外ですので、書いた人は僕のところへ来てください。お説教します。
ちゃんと誰がやっても同じ操作になるように書きましょう。

「うちテストコード書くからテスト項目書は成果物じゃないんだよね」って場合も、自分用メモ/中間資料と割り切って書いてみることを推奨します。
てかテストコードだけ見てても仕様とあってるかどうかってわからなくねぇ？僕はわかりません。

不明点が出てきますよね

さっきちょろっと書きましたが、だいたい「あれ？これ仕様に書いて無くね？」という事態に遭遇します。
例えばですが、仕様書に「項目A,Bを足し算して項目Cに出力する」としか書いてない場合、「項目Aの入力に0と1と書いてと・・・あれ、全角とかマイナスとか小数ってどうなるん？」ってなるじゃないですか。
負荷試験の観点でもそうですね。「CSVの行数を0件、1件、2件・・・あれ？MAXどこまで試験すればええん？」と、実は想定件数が仕様書に書いてないことに気づいたりもします。

こういうの、仕様書をふんふんと読んでるだけでは割と抜け落ちます。そしてだいたい実装してみてから「あれ？ここどうすんだっけ」ってなってバタバタします。手戻りもめんどくさいです。

テスト項目書を仕上げていきましょう

せっかく気づいたのでどんどん仕様書を書いた人に質問しましょう。

これがTDD風味に仕様書読んでいくの良いところです。仕様書を読み込んで理解し、かつ不明点を質問するという本来やるべきなのに抜け落ちがちな行程が自然と実施されます。

全部やれば、テスト項目も仕様確認もだいぶ正解に近いものができるので安心して実装できますねって算段です。結果闇雲に実装するより早く終わったりします。

あとの工程は現場のやり方でOK

あとは、テスト項目どおりに自動テスト書くなり、手で動かしながら作るなりご自由にどうぞ。
いったん項目に落としたことで自動テスト書くとしてもだいぶ書きやすくなってると思います。

自動テスト良いですけどね、なかなか現場で浸透しないとか時間がないとかいろいろ理由もあると思いますし、ここで大事なのはテスト項目を先に起こしておくことだと思いますので重要ではありません。

TDD風味な段取りはリーダーにもおすすめ

リーダーしてる時も、これをメンバーにやらせると、コードレビューより効率よく仕様理解の甘さを検出できるので好きです。だからコードよりまずテストをレビューします。
僕はね、ぶっちゃけ仕様通り動けばええねんって思ってますので。

コードを一字一句読んで、仕様通り動くよねって確認するの、僕はぶっちゃけ無理だと思うんですけど、むしろそれこそやり方あれば知りたいところです。
あれはせいぜい「アカン実装してないか」とかをチェックするもうちょい高次元の話だと思ってます。あるのよ、往々にして仕様の認識漏れ。

未経験からテスターになった方向けのお話

テスターから任されるってことはだいたい未経験～1年目くらいだと思いますので、仕様書読んでパターンを洗い出せと言われてもどっから手つけたらええねんってなると思います。だからこそ、既に項目があるテストでお作法を学んでください。

実装でも人の書いたコードをマネしまくると思いますが、テストもおんなじです。人の書いたテストでお作法を学びましょう。境界値がどうのと講釈垂れるより、現場で何度も「0件、1件、…」みたいな項目を見た方が頭に定着すると思います。

門前の小僧なんとやらですが、どういう仕様からどういうテストが起こされるか体で覚えてほしいです。

まとめ

僕らの仕事は本質的に「実現したいものから曖昧さを排除して、コードや設定として確定させる」ことです。その仕様理解⇒製造の工程において、テストは強力なツールだと僕はとらえています。
TDDの切り口でお話ししましたが、実はテストの重要性と、曖昧さの排除を極力早い段階で実施する方法を話したかったのです。

テストに関して現場経験からぼんやりと積み上げてきたノウハウを言語化してみました。ここまでお読みいただいてありがとうございました。