mixi TDD Challenge #5 に参加してきました! #mixi_TDD5

 

f:id:nexem:20201024233206p:plain

いただいたTシャツ。

TDD Challengeとは、mixiさんが定期的に開催している、TDD(テスト駆動開発)の1dayワークショップのことです。ペアプログラミングをしながら学ぶワークショップだということで、大学の友達に誘われて参加してきました。

テスト駆動開発とは

簡単に言うとテストコードを書いてからプログラムのコードを書きましょう、という開発の仕方です。

テストコードっちゅーのはですね、例えば3の倍数が引数で渡されたら絵文字(🤪)を出力して、それ以外の場合はそのまま引数を返すプログラムを書くとしましょう。

 

def nabeatsu(num):

  if num % 3 == 0:

    return 🤪

  else 

    return num

 

そしたら、この関数とは別にテスト関数というものを作るんですね。

nabeatsu関数は、
3を渡したら「🤪」が返ってこないとおかしいですよね?

6を渡したら「🤪」が返ってこないとおかしいですよね?
2を渡したら「2」が返ってこないとおかしいですよね?

というのを、テストコードとして書いていきます。

 

def test_nabeatsu():

  assert_equal(🤪, nabeatsu(3))

  assert_equal(2, nabeatsu(2)) 

 

assert_equalは第一引数と第二引数の値が違ったらエラーを吐くような関数です。疑似コードなんで実際の文法は言語によります。

このテスト関数を実行して、もしエラーが出たら、元のコードはどっか間違ってます。3を渡しても「🤪」が出力されなかったらおかしいですよね。

テストコードで関数の実行結果を検証していけば、その関数の実行結果がある程度保証されて安心できるよね、という理由で、テストコードは非常に大事なんですね。

以上の説明を聞くと、「なるほど実装を書いてから、テストコードを書くのね」って感じの理解になると思うんですが、テスト駆動開発ではなんとテストコードから先に書いていきます。

 

テスト駆動開発の詳細ついては、ビギナーの僕が紹介するよりも確実にわかりやすい「50分でわかるテスト駆動開発」の動画があるので、ぜひそちらを参照いただきたい。しかもこの動画で使われている言語は弊学科でもよく使われている Java です。

 

使用した言語・テストフレームワーク

Rubyの2.7.2を使いました。テストフレームワークにはMinitestを使いました。他にもRSpecなどのフレームワークがあるらしいですが、Minitestは標準でrubyについてるそうです。

 

 

テスト駆動開発でいいなーと思ったところ

後の参加者のワクワクを奪わないために、詳しい演習についてはあまり書かないでほしいとのお達しがあったので、TDDでこれいいな~って思ったところとかのみ書いていきます。

 

・バグを即発見できる

そもそもテストを先に書いてから実装を行うので、ちゃんとテストを書いてればバグはめちゃめちゃ少なくります。

 

リファクタリングへの心理的な障壁がなくなる

リファクタリング=外部から見た動作を変えずに中のコードの構造を整理する、可読性を上げること

個人で作ったプログラムとかって保守性とか何も考えずに書くので汚くなりがちなんですが、動いたからまあいいやーみたいな感じで動かしてたら、ある日突然動かなくなります。

よし治そう、とコードを見てみたらぐちゃぐちゃでよくわからん!!スパゲティコードだ!ってのを避けるためにリファクタリングはめちゃめちゃ重要なメソッドなのです。

しかし、下手にソースを変えるのは怖い!今ちゃんと動いてるのにリファクタリングしたら良く分からん挙動が発生してしまった、、なんてことが起こりえます。
でもTDDなら、テストをちゃんと書きさえすればリファクタリングを恐れる必要が無くなります。テストが通るように作ればいいのですから。

・テストコードから要件や仕様を把握できる

仕様書とかなくてもテストコードからなんとなく仕様を把握できたりするらしい。これは社会人になったら実感しそう。

 

予習しておくとよいもの・準備しておくとよいもの

今回のワークショップでここ知識が無くてスムーズにいかんかったな~と思ったところがところどころあったので、のちに参加する人がよりTDDの学習に集中できるように、予習・準備しておくとやりやすくなるものを書いておきます。

・ワークショップで使う言語の文法

今回はRubyを使ったんですが、勝手にPythonと似てる言語だと思ってたのでえっ、そんな書き方できるの OR するのっていうのが結構ありました。

・gitの使い方

普段からgitを使ってるとよいかも。リモートリポジトリを、友達をCollaboratorとして招待して一緒に編集する方法とか知っておくと便利。

ペアプロ用の環境

このイベントは二人で応募するとその二人でペアプロができるんですが、オンラインだと片方が画面共有してコーディングをする、という形になります。正直やりやすいものとは言えないです。

「あれ?こっちのファイルってどういう仕様になってたっけ」と思ってる時に、画面には別のファイルが表示されていて、「あ、ごめんもう一個の方のファイル見せてもらってもいいかな」みたいになることが結構ありました。

最近のエディターはコードを共有できる拡張機能があったりするので、ペアで参加する方はそういったものを入れておくとやりやすくなるかもしれません。

 

 

まとめ

コロナ禍でイベントの開催が難しい中で、オンライン上でこのようなイベントを開いてくださったmixiさんには、改めて感謝を申し上げたいと思います。本当にありがとうございました!

このTDD ChallengeのほかにもGit Challengeや、Bug shooting Challengeなど、様々な面白いイベントを定期的に開いているようなので、ぜひそちらも参加してみたいなと思っています。この記事を読んだ方も、一度Googleで調べてみてください👌