「テスト駆動開発」を試してみた。

テスト駆動開発」を試してみたくなったわけ

先日ブログの記事に書きましたが、いま自分はすごろくアプリを開発しています。

github.com

仕事が終わって帰宅してから、ちまちま動作確認しながら作り続けていたのですが、ふと思ったことがひとつ…。

 

テスト、めんどくさくね?

 

ここでこのプログラムを動かしたときのコンソールの様子をご覧ください。

f:id:yuya_tequila:20171206001821p:plain

 最初にプレイする人数を入力したあと、プレイヤーの名前を入力して、ターン毎にエンターキーでサイコロを振る・・・という流れになっています。

 

自分はなんと、このプログラムの動作確認に「毎回いちいち起動して目視で動作を確認する」という、とんでもなくめんどくさい方法を採用していました。

プレイヤー名が正しく表示されないときは思い当たるところを直してから動かし、ターン数表示がおかしいときはまた直してまた動かし・・・めんどくさくて当然です。

もっと簡単に動作確認しながら作ることは出来ないものかとモヤモヤしていました。

 

ある日、そんな自分に、とある言葉が天啓のように舞い降りてきました。

 

テスト駆動開発

 

テスト駆動開発という言葉を知ったのは最近です。Rubyの勉強を開始したあたりで知りました。 

最初の印象は、正直言って「面倒くさそう」でした。

 

だってテストコードをいちいち書かなくたって、動かせば一目瞭然で結果がわかるのです。それって何が効率いいの? という感じでした。

ですが実際に1からコーディングをして動作確認をしていると、毎度毎度いちいち起動して確認するほうがよっぽどめんどくさいのでは? と感じるようになりました。

テストコードを書くのは確かに面倒かもしれませんが、正しいものを一度書いてしまえば、何回でも好きなだけ動作確認できます。リファクタリングする際も思い切ってソースコードを書き換えることができそうです。

 

ああそうか・・・テスト駆動開発はこういうときに力を発揮する手法だったのか・・・などと、ひとり勝手に納得してしまいました。

や、まだTDDという概念を知ったばかりなので、そういう理解で正しいのかはよくわからないのですが。

 

前置きが長くなりましたが、そんなわけで「RSpecを勉強しよう!」と思い至ったわけです。

 

このあと実際に試してみた結果について記載したいと考えていたのですが、長くなってしまったので実践編は別の記事で更新したいと思います。 

また、「実際に動作させて確認したほうが早い」と思い込んでいたのは何故か、を自分なりに考察したので、それも合わせて書きたいなーと思っています。