@t_wadaに学ぶテスト駆動開発【CARTA 23新卒研修】

こんにちは!CARTA 技術広報の@ShuzoNです。

@t_wadaさんによるテスト駆動開発の研修を行いました

@t_wadaによる 「みてわかるテスト駆動開発」

4/12(水)、 CARTAの技術顧問である@t_wadaさんを招聘し、テスト駆動開発(TDD: Test-Driven Development )研修を行いました。

テスト駆動開発とは

テスト駆動開発とは、開発時にコードの検証を小さく重ねフィードバックを得ながら進めるプログラミング開発手法です。これにより大きな問題を小さな問題に分割し、漸進的に安心しながらコードの改善を進めることが出来ます。

具体的には、最初に実コードに期待する振る舞いをテストするコード(テストコード)を書き、そのテストコードが成功するように実コードを連続的にリファクタリングしていきます。結果的には、テストコードが実コードの振る舞いを担保してくれるため、自分たちのコードに対して自信を持ってリファクタリングが行えるようになります。

まずは、@t_wada さんの自己紹介。

サービスによって使える記号が違うため表記ゆらぎがあるそう

インターネットではライオンのAAが一人歩きしていますが、本人は全く恐くなく怒りませんので、気軽に質問してください!

また、

研修で思ったことをslackに書くと周りの人に”今どんな考えなのか?どんな状態なのか?”が伝わるので、ガンガン投稿しましょう!

と、心構えのレクチャーから本研修はスタートしました。

午前は「見てわかるテスト駆動開発」セミナー

@t_wadaによる 「みてわかるテスト駆動開発」

午前の講習は、@t_wadaさんからTDDとペアプログラミングのイントロダクション。

  • TDDとは何か
  • TDDのサイクル(進め方)
  • ペアプログラミングのやりかた

speakerdeck.com

午後は、ペアプロミングによるTDD演習

午後は、新卒エンジニア同士で実際にペアプログラミング。まずは、ペアプロミングのやり方について講習がありました

speakerdeck.com

演習の流れは以下です。

  • 新卒エンジニア同士がペアを組み、互いに役割を決める
  • 全員で与えられた演習課題に同じ取り組む
  • 事前に決められたペアでペアプロしていく
  • ペアごとに登壇し、書いたコードの公開レビュー

新卒エンジニア同士がペアを組み、互いに役割を決める

ペアを組み、交代でコードを書き進めます。

  • 書く人: ドライバー
  • 一緒に考える人: ナビゲーター

全員で与えられた演習課題に同じ取り組む

解く課題は全員同じです。ペアによって希望を出した言語で実装を行っていきます

  • Go
  • TypeScript
  • Python

事前に決められたペアでペアプロしていく

和田さんと講師陣がサポート

  1. テストファーストのアプローチでコードを書く
  2. モニターのコードの指差し確認しながらコーディング
  3. 一定時間でドライバーを交代していく
  4. プログラミングの速さを競わない
  5. 最終的に、書いたコードを画面に写し、公開レビューを行います。

新卒エンジニアたちのテスト駆動開発に対する印象変化

研修を通して、テスト駆動開発に対する印象変化があったようです。
新卒たちは、研修前に2時間の予習動画を視聴しているため、「テスト駆動開発がなにか」はなんとなく知っている状態からスタートしています。

また、内定者バイトをやっている人とそうでない人で関わり方も知識も人によって違います。

研修前におけるテスト駆動開発の利用率

研修前は

やり方が分からず、メンテが面倒で、やり方がよくわからない、無くてもなんとかなる

研修後は

関数のインタフェースや命名について"どういうものがいいんだっけ?"と設計について意識できるようになった

「設計」に意識が向く ようになったそうです。

テストファーストなコーディングを行うことで、対象のコードは「動作するだけ」のものから「動作するし設計も考慮された」コードに変化を遂げます。

テストコードは、実コードを「使う側からの目線」で検証するため、その使い勝手や役割の伝わりやすさに意識が行きます。その結果、インタフェースや命名が気になるようになったのでしょう。

まさに テスト駆動開発が設計の治具 になる瞬間を体感したようです。

以下はアンケートから新卒たちの声を引用

before

  • テストの書き方や粒度が難しい。
  • コードを新しくしたときにテストも追従させるのが難しい。
  • どこまでテストするのかや、ここはテストしなくていいって線引きの基準がわからない。
  • 実装した後にテストを書くって流れで開発してしまう。

after

  • 大切なことを理解したのと、想像をしていた面倒臭さではなくうまみの大きさを感じました。
  • TDDでない開発と比べて、着実に一歩一歩実装を前進させ、実装したコードが強固になることが実感できた。
  • テストファーストにすることで、いち早く要件の仕様漏れに気がついて、ソフトウェアの品質が担保しやすいと思った。
  • テスト駆動開発をしたことがあったのでわかったつもりになっていたのですが、全然そんなことはなくて、特にテストケースとしては十分だけど品質保証にテストを利用しようとした時のテストの書き方やテストケースの命名の仕方、メンテナンスコストを増やしたり可読性を下げることなく品質を向上させることのできるコードの書き方などすごく勉強になりました。そしてまだ勉強が足りないことも実感しました。

以上、当社で行ったTDD研修についてのレポートでした!


新卒採用はこちら

carta-recruit.snar.jp

中途採用はこちら

hrmos.co