MIXI TDD challengeって？
ユズキちゃん (Custom Instructionで改造したGPT-4) に聞いてみました。
言いたかったことを全部言ってくれました。強すぎる。
▼▼▼ 今年の募集ページ ▼▼▼
▼▼▼ 2020年の開催レポート ▼▼▼
当日の流れ
@cp20 視点で当日の流れを語っていきます。
会場に行く
今回のTDD challengeの会場は渋谷スクランブルスクエア36FにあるMIXIのオフィスでした。10:40に集合で、10:30に渋谷駅に到着したら余裕あるよ～みたいな連絡がなされていたので、10:30ピッタリに渋谷に到着する電車に乗ったら2、3分遅延した上に、普通に迷って5分ほど遅刻しちゃいました。申し訳ないぜ、、、
イントロダクション
最初は諸連絡とか、チューターさんたちの紹介がありました。あとアイスブレイク的な感じで好きな言語をSlackに書いてみましょうみたいなパートがあったんですが、Goが人気過ぎて、、、TypeScript派もちょっといて嬉しかったです。
そして本題へ。TDD challengeということでテストが重要になってくるわけですが、テストについてまず説明をしてもらいました。テストとは何か、テストはなぜ必要なのか、手動テスト・自動テストの違い、テストを書くと何が嬉しいか、実際のテストの書き方 (Ruby + RSpec) などを教わりました。
これは余談ですが、スライドの絵が手描き感溢れる、温かみのあるかわいいデザインで良かったです。
#MIXI_TDD 、始まりました～！
— MIXI 新卒採用公式アカウント (@HR_mixi) October 1, 2023
皆さん、よろしくお願いします！
楽しんでいきましょう🎵 pic.twitter.com/sR4QUqgYJW
チュートリアル
最初にサンプルを実行するみたいなパートがあったんですが、意外に躓いてる(?)人が多くて、やっぱ環境構築って沼やなあぁという思いを抱きました。事前に環境構築してね、みたいな連絡があってもこうなっちゃうのね、と。
まず手始めに、簡単な問題を解きました。シンプルな仕様で、それを満たすテストを適当に書いて、実装も書いて、という感じですね。ホントにシンプルなので、すぐに書けちゃうんですが、仕様書の日本語を読み取るのがちょっと難しかったですね、、、それに対するチューターさんの発言が
業務でこういう仕様の食い違いめっっっっっっっっっっっっっっっっちゃあるから今体験させてあげたんだよ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
なるほど、一理ありそうですね(((
お昼ごはん
お昼ごはんは牛丼か天丼か選べました。どっちも美味しそうで迷いましたが、ボクは牛丼を食べました。美味しかったです。
席がチームごとに決まっていて、テーブルに1人か2人かチューターさんがいてくれるという感じでした。ボクは久野さんと一緒のテーブルでした。久野さんはめちゃめちゃ親しみやすい感じで、これがコミュ強か、、、という。MIXIがめちゃめちゃ働きやすい環境だよという話とか、(あんまり知らない分野でも) 勉強会とか行きまくって顔広げとくといいよという話とか、いろいろお話してもらいました。これだけでも来た価値があるぐらい。
他のメンバーさんたちもインターンとか行きまくっててめちゃ強そうな感じでした。なんならボクと別のチームの2人が今年のサマーインターンで知り合った仲だそう。そういう繋がり欲しすぎる～～
TDDにチャレンジ
TDD challengeということで、本題のTDDとは何かという説明を受けました。Red・Green・Refactorの流れを実際にどうやって書いていくかというところも含めて教えてもらいました。
そしたら実践ということで、さっきよりはちょっと複雑な問題に挑戦しました。最初の問題は個人で解いてみるという感じだったんですが、今回からはペアの人と一緒にペアプロで進めていく感じでした。
真ん中に一台ディスプレイが用意されていたので、それにパソコンを繋げて2人でその画面を見ながら進めていきました。問題自体はそこまで難しいものでもなかったので、適当にテストを書いて、GitHub Copilotにだいたいコードを書いてもらって、デバッグして、終わりです。ボク的には普通に進めてるつもりだったんですが、かなり早かったらしくて結構驚かれました。
責務・副作用を意識した問題
少し副作用を含む処理が入ってくる問題で、その副作用をどう処理するかみたいなところがフォーカスポイントでした。事前に責務・副作用に関わる設計に関しての説明がありました。テストが書きやすい設計というのが良い設計で、それは責務が分かりやすいかつ大きすぎない、そして副作用がなるべく排除されている設計だよという話をされました。今回は設計の話がメインではないのでそこまで深くは踏み込まなかったですが、そういうところまでしっかり触れてるの良いねと思いました。
チャレンジ問題
最後にチャレンジ問題を解きました。これはマジで難しくて、まず仕様を適切にテストに落とし込むのがすごい大変でした。もちろんテストですべてのケースを網羅することはできないので、どのケースを入れるのかというところがすごい難しかったです。
今回仕様がいくつかのセクションに分かれている感じだったので、テストコードもそれに合わせて分割して書きました。こうやって書くのが正解なのかは良く分かってなかったんですが、後でチューターさんに聞いてみたら、むしろその方が読みやすくて良いみたいな話をされたので良かったです。
テストコードを書くのも一苦労だったんですが、それを満たすような実装を書くのも一苦労です。でも特に詰まることはそんなになく、頑張って書いていたんですが、時間が足りませんでした、、、悔しい...！
時間内に書けたコードだとテストが一部落ちていたのでたぶん採点も無理だろうなぁと思ってたら案の定無理でした。色々あって時間オーバーしてもちょっと書く時間をもらえたんですが、ちょっとデバッグしたらしっかりテスト全部通って、採点もパスしたので良かったです。でも逆に時間内に終わらせられなかったのが悔しい...！最終問題はGitHub Copilot禁止と言われてしまったのでそれで時間がかかったのもあるかもしれません。
懇親会
最後には懇親会がありました。お昼ごはんの時と同じく、1テーブルにつき参加者数名 + チューターさんという感じでした。1回シャッフルを挟んで色んな人とお話しできました。
受験の話とか、部活動の話とかをしたり、皆さんが普段どういうことをやっているのかみたいなのを聞いたりもしてました。Goが最近人気だよねという話から、Javaってどこで使われてるんだろうみたいな話になったりもしてました。
学び
@cp20 が学んだことを勝手に書いていきます。
TDDの概念自体は知っていたんですが、実際にしっかりTDDをやってみたことはなかったので、すごい良い実践の機会になりました。特に最後の問題に関しては、普段のボクなら実装から書いちゃう気がするんですが、あえてテストから書いたことでしっかりと仕様を満たす (コーナーケースもしっかりカバーする) コードが書けた気がします。一発で書いたコードは絶妙に一部のケースが落ちてたので、そのまま書いてたらバグに気付かなかったんだろうなぁ、、と。
でも上のやつはTDDの良いところではなく、テストの良いところなんですよね。TDDの良いところは、仕様書をコードに落とし込むことで、実装の時に自然言語特有の曖昧性を排除できるところなんじゃないかなぁと思いました。今回TDDをするにあたって、ボクはこんな感じの流れで進めてました。 (少しずつテストを書いていくというやり方もありそうですが、ボクは最初に一気に全部書いてました)
- 仕様書を見て読解する
- 仕様書をテストに起こす
- テストを見ながら全てのテストケースを通すようなコードを書く
3のところがキモで、テストを書いた段階で仕様書はもう見る必要がないんですよね。 (仕様書を正しく読解して正しくテストに起こせているという仮定が必要ですが) テストを見ながらテストケースを全部パスするようなコードを書けば、自然とそれは仕様を満たすようなコードになるという。必要であればそれをリファクタしてさらにキレイにするという感じですね。テストコードを見ながら実装していると「俺TDDやってるわ～」感が出るのでオススメです。
あとボクはペアプロをあんまり経験したことがなかったので、どうやって進めるのがいいのかとかも分からない状態でやってました。ドライバー (コードを書く側) とナビゲーター (指示を出す・ミスを指摘する側) に分かれて進めるわけですが、ドライバーだと進めてしまってナビゲーターを置き去りにしてしまっている感があるし、逆にナビゲーターだと自分の思考を上手く相手に伝えるのが難しいなと思いました。おそらくペアプロを上手く進めるためにはコードを書くのに必要なコンテキストをお互いに共有している必要があるんだろうなぁと。
今回はRuby + RSpecを使って進めていく感じだったんですが、ボクはどっちも使った経験がありませんでした。なのでChatGPTに書き方を聞いて、GitHub Copilotに書いてもらって、動かなかったらちょっと修正するみたいな感じで進めていました。今回はテストを書くということが本題(?)なので、テストを自分でしっかりと書けば、中身の実装に関してはGitHub Copilotに書かせようが、ChatGPTに書かせようが、自分で頑張って書こうが、テストを全部通せれば何でもいいよねみたいな。これがホントのTDD...？それはそれとしてRubyを書いた経験を1ミリ積めたのは成長かなと思います。
感想
@cp20
今回MIXIの側からtraPにお誘いが来たので割と軽い気持ちで参加したんですが、かなり多くの学びがあったり、いろんな人と知り合って話せたりと収穫が多いイベントだったと思っています。技術系イベントあるあるですね。(ボクが勝手にそう思ってるだけかもしれないけど)
TDD Challengeの前にあったGit Challengeはめんどくて放置してたんですが、機会があれば応募してみてもいいかもな～という気持ちになりました。次回もMIXIさんからお誘いが来ないかな～ (ﾁﾗｯ と思っています。
@ikura-hamu
前からTDDには興味があったもののなかなか手を出せずにいたので、今回お誘いを受けた時はすぐ食いつきました。ちょろい。
現役のエンジニアの方から直接教えていただき、とても学びになりました。普段の開発では実装→テストで書いてたのでテスト面倒だなという気分でしたが、仕様を満たすようテストを書きながら実装を進めることで、テストを書くのが面倒でなくなりそうだと思いました。GitHub CopilotとかChatGPTのおかげでテストケースを考えるのも楽になってきているので、ちゃんとテストを書けるプログラマになろうと思いました。
MIXIのみなさん、ありがとうございました。
@noc7t
今まで散々テストから逃げ回ってきましたが、流石にそろそろテスト書けるようにならないとまずいだろ、と思って参加しました。
実際にテストを書いてみるときにこのテストケースではどういった値が返ってくるのが正しいのかみたいなことを考えて書くと、細かい仕様がどうなっているのかを把握していないと書けなくて、講師の方が「テストを仕様書の代わりにする」みたいなことを言ってた理由をなんとなく理解できた気がします。
テストを少しづつ書きながら実装を書いていく、みたいな手法を紹介されたのですが、どうしてもテストの書きやすい順番と実装をやりやすい順番が違ったりしたのもあって、ちょくちょくテストにない実装をしちゃってたところがあって反省してます。もう少し大きなまとまりに分割しながらテストを書いていくべきだった気がしてます。
実際にテストを書いてみて、意外とテスト怖くなかったな、ってなったので、機会を下さったMIXIの方々には感謝です。
さいごに
MIXI TDD challengeを開催して、そしてお誘い頂いたMIXIさん、運営やチューターとして携わってくれた社員さん、一緒に作業した参加者の皆さん、本当にありがとうございました！！
