テストコード初心者にテストの書き方を教えた感想

↓をやり終わったため感想をまとめておく。¹

どのように進めたか

最初はプログラミング初心者です！配列やfor文も難しい！状態の人が多かった。かなり平均値を引き上げられたのではないかと思う。

参加者に感想を聞いたときに次のようなコメントがあり、印象に残った。

単体テストは上級者が書く難しい何かだと思っていたが、初級者ほどテストを書いて通す方がいい。

知らないことに対するハードルが高いので（これは自分もそう）、誰かがきっかけを作ると良いのかもしれないと思った。実際やってみると意外と！というものもあれば、その逆もある。まずはやってみるのが重要。

とにかくやってみれば？と思ってしまうかもだが、初級者にはハードルが高い。次の流れがないと学習が進みづらいご時世なのかもしれない。

問題は1の時点で詰みやすいこと。周りの人にできる人がいない・できるけど教え下手な人しかいない、だと成り立たない。色々な環境に行くなど、自分から行動する必要はあるかもしれない。最近はYoutubeとかに色々上がっているし。

2と3には厚い壁があるのも詰みポイントで、トレースした内容を応用する、で詰まってしまう人がいる。これは心構えの話なのでテストコードがどうこう、ではなさそう。

テストがあるとデグレードを気にしなくて良い（テストで気づける）ので、とても安心感がある。

初級者は不安を覚えやすい。「あっているかどうかわからない」と言うことが多い。なるほど？あってるかどうか、は誰が判断するの？テスト結果だよね、から始める必要がある。不安を取り除かないと手が止まりやすい。「あってるかどうか」を明確に示せるテストは不安を克服する訓練としてとても良いのではないか。

小さく変更してすぐテストを回す習慣ができた。

大きく変更して「何書いてあるかわからん…」となるのはありがちだと思う。テストを回すように指示すると「一度にたくさん直すとたくさんテストが落ちてつらいなあ」という気持ちになる。大量にテストが落ちてしまうと直すのが本当にしんどくなるため。

必然的に小さく変更してすぐテストを回す→git commitするようになる。つらみポイントを感じると行動が変わりやすい。

ルールが明確でない・参加者の中に正解を知っている人がいないものをお題にすると、「ルールを調べて時間が終わる」本末転倒な状態になってしまう。これは良くなかった。

具体的には題材になりやすい「ボウリング」を2つ目のお題にしたが、ボウリングはあまり行かない・行ったことがない人ばかりだった。スペア・ストライク（特に最終ゲームのストライク）のルールがイマイチ理解できず、テスト結果が間違っているのか、そもそもケースが間違っているのか判断できかねる箇所が多かった。

ケースが間違っている可能性があると練習にならないため、電卓で正解が出しやすい計算系のお題にすればよかった。

色々テスト駆動開発のお題を見て簡略化すると良さそう。

勉強会でお題が出てくる前に自力で実装＆テストを通しておいた。これはとてもよかった。詰まりやすい箇所をあらかじめ把握できる。すると手が止まってた場合「〇〇は検討した？」などのアドバイスもしやすい。事前に見通しを立てておくと良い。

関連書籍を読み直して言葉の定義を確認しておくのもよかった。間違えたことを堂々と伝えてしまうリスクを減らすため。結構「あの人が教えてくれることは全部正しい」バイアスがかかりやすいので、下手なことは言えない。

自分も勉強するきっかけになった。また、わかっていないことは教えられないため、自分の理解度をチェックするのに良い場だった。