mixi engineer blog

ミクシィ・グループで、実際に開発に携わっているエンジニア達が執筆している公式ブログです。様々なサービスの開発や運用を行っていく際に得た技術情報から採用情報まで、有益な情報を幅広く取り扱っています。

新卒研修受講レポート~テスト編~

はじめまして、17新卒エンジニアの村上と林です。

今回は「テスト」という「プログラムが正しく動作しているかチェックするためのプログラム」についての研修を受けたので、まとめていきたいと思います。

 

本研修の内容は以下のようなものでした。

・テスト/設計についての簡単な講義

・ペアプログラミングでの実習

  • 車窓からのTDD
  • 円の面積を求めるプログラムをTDD
  • emailアドレスの正誤判定プログラムをTDD

 

テストについての簡単な講義

 

テスト研修の目的

まず、なんでこんな事やるの?という事で、研修の目的について述べたいと思います。

研修の目的は「良い設計を覚える」、これだけです。

 

良い設計ってなんなの?

そこで、良い設計とは?となると思います。

疎結合?可読性?

色々あると思いますが

「経営的な要求・条件に応えられること」です!

経営判断としてスピードが求められる場合には可読性よりも開発スピードを優先する場合もあります。良い設計に重要なものはその時の状況によって変わるということです。

 

しかしながら、突然のメンバー変更や仕様変更などが往々にして発生し、保守しづらいコードでは何をしているのかよく分からなくなるため、結果的に保守しやすい設計の方が(引き継ぎなども含めて)開発スピードが早くなります。

なので今回の研修では「保守のしやすさ」に焦点を当てます。

 

いい(保守しやすい)設計方法

保守しやすい設計方法として、テスト駆動開発(test-driven development:TDD)を利用します。この手法では、大きく3段階の手順を踏みます。

  1. テストを書く
  2. テストを失敗させる
  3. 実装してテストを成功させる

この3つの手順を実施することにより保守しやすい設計になります。


TDDのメリット

メリットは以下の3点です。

・テストを先に書くので、テストしづらいコードを書けない

・テストしやすいコードは疎結合で副作用もなく分岐も少ない

・この作業をやっていくと自然に保守しやすい設計になる

 

ペアプログラミングでの実習

ここまでの講義内容をペアプロで実践しました!

(※ペアプログラミング: 2人でプログラミングすること。常に片方がレビューをやっているので様々なメリットがある)

f:id:mixi_engineers:20170510162530j:plain

車窓からのTDD

「車窓からのTDD」はweb上に公開されており、内容としても簡単なのでTDDを体験してみたい方はリンク先を確認してみてください!

http://objectclub.jp/technicaldoc/testing/stack_tdd.pdf

 

「車窓からのTDD」には対話形式でTDDのやり方が書かれており、手順通りに進めていくだけで良いため、手始めのTDDの理解にとても役立ちました。

 

「車窓からのTDD」はスタックを構築するだけの簡単な内容で、上記したTDDの流れの通り、テスト作成し失敗、実装、再度テストを実行させ成功、のサイクルで行います。これはTDDでは基本の流れになります。今回の研修では、各自経験のある言語(RubyやPythonなど)で作業を進めていきましたが、どの言語でも基本の流れを抑えれば大丈夫です。

 

テストを書いてから実装をするので、実装の目的が明確になることで無駄なコードが減り綺麗なコードになると感じました。


円の面積を求めるプログラムをTDD

この課題では、「標準入力経由で円の半径が渡されるので、円の面積を求め四捨五入して整数に丸める」というプログラムを書いていきました。

入力が外から入ってくるため入力値に対するテストが必要になります。

この課題の採点が一回しか行われないという条件だったため、絶対に正解するように多くのテストを書きました。

(テストケースをたくさん書いて置くことで途中でコードの間違いを素早く見つけることができました。間違いなく実装するという点においてもすごくテストが役に立ち、重要なんだと実感しました!)

 

また、今回の課題でのポイントは標準入力でデータが渡ってくるという点です。テスト(今回の場合ユニットテスト)はロジックだけをテストしたいので依存性がないものが理想です。標準入力に依存しないように、スタブやモックオブジェクトで切り離す方が良いでしょう。

 

emailアドレスの正誤判定プログラムをTDD

「emailアドレスが"RFC5312 addr-spec"の部分的な仕様として正当なものであればok、違えばng」のテストを作成しました。

今回の場合、大量のテストケース(ngになるメールアドレス、okなメールアドレス)が必要になります。

なので、どのテストケースで失敗したかを分かりやすくする工夫が必要でした。

 

テストの速度は上げつつ、どこで失敗したかを判別したいのですが様々な方法があるようです。Rubyの黒魔術的な方法もあるようですが、後日調べたところこのような書き方もあるようです。

qiita.com

 (テスト書いててどんなテストケースあるかなってなったとき、キレイに書いてると「このケースもあったな」となりやすいので、保守性と速度が確保されると感じました)

 

まとめ

今回の研修ではテストの重要性について学びました。

保守しやすい設計で、引き継ぎの方や後輩達に、先輩はいいコード書くやろ?ってドヤ顔しましょう!!!!