未だにspec(テストコード)の必要性を感じません。皆さんはどういった時に、specを書いていてよかったなと感じられますか？

Question

最近になって初めて、specを書くプロジェクトに参画しました。

これまで、ずっとruby on rails でのプロジェクトをやってきましたが、
運よく？sepcを書かないプロジェクトばかりでした。

私自身、あまりspecの必要性を感じなかったため、さほどspecの勉強をしてきませんでした。

これが良いきっかけでしたのでspecを書く練習をしております。

ただ、どうしてもわからないのは
どういったときにspecが役に立つのかです。

私が不慣れなせいなのか、以下のような疑問を感じてます。

---

・specを書いても、結局、specを書いているロジックの実装を変更した際に、specも書き直さないといけない。（specは書いたら終わりじゃなく、メンテナンスが必要）

・specを書いても、画面などで動作確認する

・specの必要十分性がわからない。（どこまで書けば、十分なテストなのか）←こちらに関しては経験次第？かと思いますが

---

そういうことを考えていると、ならテストいらないかなと考えてしまいます。

とはいえど、せっかくspecの勉強をしているので、次のプロジェクトのときにも使えるように、specを書いていてよかった例、specがなかったせいで、ひやっとした例などございましたら、是非、お聞かせ頂けると幸いです。

宜しくお願いします。

Answer 1

最近、単体テスト、結合テストの方法についてで近い話題があったので参考になると思います。

xSpecはTDDというよりBDDを目指しているフレームワークなので、より最終的な外部仕様を表現する意味合いが強いです。

・specを書いても、結局、specを書いているロジックの実装を変更した際に、specも書き直さないといけない。（specは書いたら終わりじゃなく、メンテナンスが必要）

specは振る舞いそのものなので、詳細仕様書と同じ扱いになるのが適した使い方だと考えています。詳細仕様書があってさらにspecを書くとなるとメンテナンスが大変ですが、specだけならそれが唯一の詳細仕様書（通常の詳細仕様書とは違い、その通り動くことが約束されている）ので、メンテナンスを行う価値があります。

・specを書いても、画面などで動作確認する

画面を含めてspecを書ければいいのですが、画面仕様（デザイン的な部分や機能に関係無い共通表示部分）まで含めると定義しきれないので、一つの区切りとしてspecを使うしかないのかなと思います。
画面動作まで含めたテスティングフレームワークも存在するので、組み合わせて使えればベストですね。

・specの必要十分性がわからない。（どこまで書けば、十分なテストなのか）←こちらに関しては経験次第？かと思いますが

前述のページのベストアンサーの

1. 結合テストのケース作成について

部分が非常に参考になります。

Comments

[qaz3330]

ご回答有りがとうございます。

>単体テスト、結合テストの方法についてで近い話題

すごくまとまっていたので、こちらも熟読させて頂きます！

また、ちなみに、現状、テスト作成者と実装者が同じ人（自分）がやることになっているのですが、
これが普通なのでしょうか？

テスト作成者が仮に別で、かつ、発注者とかであれば、確かに、
すごく良さそうな気がします。

※詳細仕様書は発注者の方で作成されており、それをもとに実装と、specを書くというイメージです。

[tanat]

実装するのは別に誰でもいいのですが（TDDだとクラス実装者がテストも実装することが多い）検収するのは別の人（責任者）で無いとそのspecなりテストが仕様に沿ったものか分からないので、テスティングフレームワークを使う意味が単なる言い訳になってしまいあんまり開発効率や質に寄与し無くなってしまうと思います。

Answer 2

テストコードを書く意義、大局的にはこの2点が大きいかと考えています。

• 良いコード習慣の強制
• リファクタリングをするための必要条件

良いコード習慣の強制というのは、テストコードを書くためには製品コードの側もテストを書きやすい構造になっている必要があるため、必然的に疎結合で副作用が少なくて入出力仕様がはっきりしていて責務が単純なコードを書かざるを得なくなるということです。結果的に、とても良いコードになります。

リファクタリングをするための必要条件。製品コードがバージョンアップを進めるにつれてこんがらがった訳のわからないコードになっていくのは何度も経験されていると思います。コードの体質改善を随時していかないと拡張困難・デバッグ困難な闇鍋になるのは時間の問題です。ではその体質改善つまりリファクタリング、やれば良いというものではありません。
「動いているコードをいじるな」とよく言われるとおり、良くしようとしていじったばかりにデグレ、バグを作り込んでしまうのは商売でソフトを書いていたら致命的なミス。リファクタリングにあたってデグレだけは避けねばならないのです。
そこで自動テスト。もともとグリーンだったテストがリファクタリング後もグリーンなら、ミスがなかったことがある程度保証されます。もちろん完全な保証ではないけれど、リファクタリングはしなきゃいずれ死ぬのは自分、命綱が付けられるなら頼ろうよ、というわけです。

Answer 3

Ruby開発経験はないのでRSpec固有の事情は分からないのですが、という点と、RSpec自身ではなくてユニットテストなどのテストコードの存在意義を疑問に思っているのですよね？という前置きをしたうえで…

自動テストが本当に効果を発揮するのは、該当機能開発時ではなく、保守やそれ以外の追加機能拡張時だと考えています。

結局、specを書いているロジックの実装を変更した際に、specも書き直さないといけない。

逆に言うと、ロジックを変えていない(はず)であれば、specの修正無しでpassしないといけないわけです。既に自動テストが存在していればコスト無しでテストできますが、回帰テストを手動でやろうとすると修正が無かろうがかなりの手間がかかります。

specを書いても、画面などで動作確認する

程度問題ではあるのですが、例えば自動テストがあれば回帰テストはそれで済ます、といった選択も採れますので、必ずしも画面での動作確認は必要ではなくなります。

1回きり、あるいは新規開発時のことだけを考えると、確かに旨みは少ない/無いように感じますが、将来に渡って何回同じテストをする必要があるのかを考えると、メリットも理解できるのではないかな、と。

Comments

[qaz3330]

ご回答有りがとうございます。

Rubyにかぎらずですが、現状、テスト作成者と実装者が同じ人（自分）がやることになっております。
これは普通なのでしょうか？

テスト作成者が仮に別で、かつ、発注者とかであれば、確かに、
すごく良さそうな気がします。

>将来に渡って何回同じテストをする必要があるのかを考えると、メリットも理解できるのではないかな、と。

確かにまだspecの運用して日が浅いため、しばし様子を見てみようと思います。

[退会済みユーザー]

誰がテストを作成するか、というのは、テストの性質によると思います。ユニットテスト的なものであれば実装者が作成することが多いでしょうし、受け入れテスト的なものであれば別の人が書くこともあるかと思います(ただ、ケースは他者が作るがテスト実装自体は実装者が行うことも(スキルセット的に)めずらしくはないでしょう)。RSpecはどちらのテスト向けにも使うことはできます。

Answer 4

多分TDDのツールの名前なんですよね？
一つ一つ賛成の立場に立って反論を書くと

specを書いても、結局、specを書いているロジックの実装を変更した際に、specも書き直さないといけない。

従って、テストを実行してみて正常終了しないプログラムは修正後テストをしていないと言える。
テストが通れば、テスト作成者の意図と少なくともそのテストはクリアしている事が証明できる。

specを書いても、画面などで動作確認する

テストは仕様に沿ってその通りに動作することを検証するもので、画面確認はツールとしておかしな動作をしていないか確認するものである。
数値を入力し、ボタンを押せば結果が出るテストを書きそれが正常動作していても、ボタンが画面外に出ていて人間には押せないなどは画面で確認するほか無い。

逆に小さな修正があるたびに画面で値の極限値のチェックを行う(本来そこに修正は無いはずで従って問題が出るはずも無いが、とかく人のすることは信用できないので)のは手間であるが、テストを組んでいればついでにチェックされる。

specの必要十分性がわからない。

TDDなら仕様を参考にその仕様に沿った動作を確認するテストを書き、プログラムは初回わざと失敗させその後成功するように書き直して、テストが正常動作することとプログラムが正しく動作した事の両方を確認するって手順だったはずなので、仕様に出ている項目で確認できるものを全てなんでしょうが、粒度は現場次第でしょうか？

とはいえTDD自体にも賛否があるみたいです。

Comments

[qaz3330]

ご回答有りがとうございます。

現状、テスト作成者と実装者が同じ人（自分）がやることになっているのですが、
これが普通なのでしょうか？

テスト作成者が仮に別で、かつ、発注者とかであれば、確かに、
すごく良さそうな気がします。

>初回わざと失敗させその後成功するように書き直して

こういうことは知りませんでしたので、大変参考になりました。
TDDということから再度勉強し直そうと思います。

[hirohiro]

テスト駆動のフレームワークで書くテストは、開発者が仕様を理解していることと、作ったものがその理解に沿って動作していることの証明になりますから、基本開発者が書くものと思います。
> テスト作成者が仮に別で、かつ、発注者とかであれば、確かに、すごく良さそうな気がします。
開発者が書くテストに求められるのは、仕様に対して正確に動作していることと、その細かい確認をリビジョンアップの度に確実に行っていることかと思います。
細かい仕様変更があった際に、第三者のテスト人員がそれに正確に追従するのは結構大変ですが、TDDだと開発者は修正時に同時にテストを書くわけですから確実です。
また本文にも書いたように、修正の入っていない問題の出ないはずの部分も毎回ついでにチェックされます。
これは本来修正の必要のない部分にうっかりデグレが入っていないことの確認にもなります。
ユーザ視点の品質テストは別の人間が別途行うとおもいますので、このテストではそういう部分は重視されないはずです。