アーキテクチャにのっとって、テスト駆動開発を行ってみましたので、その有用性を書いていきます。設計を初めてやった人が、ついでにテストをやってみたら、どうなったのか?それでは、ご覧ください。最後にぜひ、前の記事もお読みくださいまずは、こちらの記事を先に読んでいただくと、ご理解いただきやすいです。制作しているゲームのアーキテクチャ設計をしています。書かれてある内容を、可能な限り再現しています。今回の記事は、その続きとして、テスト駆動開発について書いていきたいと思います。さんが、技術書だけの同人イベント「技術辞典5」で出展していたものです。現在は、無料で公開されており、誰でも読むことができるようになっています。開発事例」を参考に書かせていただきます。テスト駆動開発を行おうテスト駆動開発をするにあたって、やはり、内容をある程度理解しておく必要があります。テスト駆動開発とはテスト駆動開発をざっくりと説明しますと、プログラム開発手法の一種です。進め方を簡単に説明します。動くプログラムを書く前に、先に要件をテスト&チェックするコードを書きます。そのままだと、テスト結果は、失敗(レッド)になります。これを、いったんテストがとおるコード(グリーン)を書き、エラーをなくします。後日ちゃんと作り込み(リファクタリング)を行うのです。テスト駆動開発の詳細を知りたい方は、こちらの記事が参考になります。記事みた中で一番、平文で読みやすく、芯をくっているような気がします。モバイルアプリサービス部の中安です。Development...ところで、なぜ、テスト駆動開発をする必要があるんでしょうか?テスト駆動開発のメリットテスト駆動開発のメリットを表すと、こんな感じだと思います。私が一番いいと思うのが、開発者の心理的な負担の軽減です。少なくとも、レビュアーは、テストに書かれている要件については、全て通っているという前提で、レビューできます。開発後期となると、不安になる修正の影響範囲とエンバグ問題。行を変えるだけでも、緊張が走ります。場合によっては、それだけで結構デバック工数も発生しますよね。テストを書いていくことで、そこに書かれた機能要件は満たしていることになり、余計なチェックや心理的な負担も減ります。テストがし辛いクラスや、テスト工数が多すぎるクラスは、設計上、何かしらの問題があります。そこも、見える化されそうなのも、副次的なメリットかもしれません。これは、コードを書く側も、見る側も幸せになれそうです。開発でテストはいらない?はい。私もそう思ってました。実際にテストを書くまでは。私自身、実際に運用にはのせているわけではないので、今後進めるのであれば、様々な問題に対処する必要は出てくると思います。それを差し置いても、テスト駆動開発の有用性は、ひしひしと感じました。稼働すれば、チーム開発を行う上での、エンジニアの心理的な負担が、だいぶん減りそうです。ビヘイビア(振る舞い)駆動開発と言うべき?今まで、テスト駆動開発やったことなかった私です。「テスト駆動開発」という言葉に、ぴんと来なかったんですよね。ビヘイビア(振る舞い)駆動開発と聞いて、納得しました。簡単に言うと、テストコードに書く内容に、要件にのっとった振る舞いを書く。それなら、先に書いておくメリットがわかりやすく伝わります。「先にテストを書く」、というより、「先に振る舞いを書く」。言った方がしっくり来ますよね。実際、要件(振る舞い)を先に決めてしまう手法ですので、ビヘイビア(振る舞い)駆動開発というべきかもしれません。injection)テスト稼働開発をするにあたって、疎結合を維持するために必要とされるテクニックである、依存性の注入。こちらの説明をしていこうと思います。記載がありましたが、今回は説明しません。依存性の注入を行いやすくするためのフレームワークです。ありませんので、ご注意下さい。内容は、下で説明したものを、より簡単に行えるものだと思って頂ければと思います。アーキテクチャを、マネするにあたって、メリットのわからなかったこの書き方。}}なぜ、わざわざ、外側から必要データを渡す必要があるのか?元の記事では、なぜ、そのようにしているのかが、はっきりと書かれて無かったため、意図を汲み取れてませんでした。これこそが、テスト駆動開発に重要な役割をしめしているのです。DI)とは上記にあるような、クラスに必要なパーツ(クラス)を外部から取得するテクニック。依存性を注入するという、非合法の香りただようネームですが、れっきとしたソフトウエアの設計(デザイン)パターンです。いう名前ですが、もとの意味としては、「オブジェクト」に近いです。じっさいには「依存オブジェクトの注入」というほうが、より内容を表していると思います。意味としては、そのクラスの成り立ちに必要で、依存しているオブジェクトを、外部から注入するソフトウエアパターンのことです。依存性の注入(DI)を行うと、以下のメリットがあります。要するに、オブジェクト同士のつながりが薄く(疎結合に)なるから、パーツ単位で取り出しやすいし、変化にも対応しやすくなるよね。テストを書いたら、書きやすいなぜ、依存性の注入(DI)を行うのか?それは、テストコードを書いて分かりました。すごく、テストが書きやすいのです。()をテストしたいと思います。}}上記のコードを、テストするサンプルコードがこちらです。"名前は、サンプル名です。}}初期化も簡単、テストも簡単なのが、理解できると思います。テストする場合、受け取るのは、中で隠された文字列になってしまいますので、特定の文字で比較ができません。示された書き方だと、なぜテストが書きやすくなったのか、説明していきたいと思います。テストが書きやすかったのかなぜ、テストが書きやすかったのか?それは、当たり前ですが、そのクラスが必要なパーツを、外部からカスタマイズできるようにしたからです。そのため、データの変更を外部から行うことが可能になっています。ひとつは、参照元を上位クラス(インターフェース)から行っていることです。こちらのテストの部分に絞ってクラスの参照を書くと、このようになります。見ると、共通のインターフェース(ベースクラス)を経由してやりとりしているのが分かりますね。このように抽象クラス参照しあうのには、メリットがあります。それは、実体クラスを簡単に変更できることです。今回の場合は、注入するデータをテスト用データに置き換えました。テストコードを書くときに、簡単に記述できたのです。設計がしっかりしているテストコードを書いてみて思ったのは、テストが書きやすいコードは、設計がしっかりしているとも取れるということ。仮にテストが書きづらいものが出てきた場合、設計そのものを見直すべきという、注意サインになるかも知れません。テストを書いていて、このようなことが起こった場合。依存性のあるクラスが隠蔽されている可能性これらのケースが出てきたら、メンバーと相談するのが良さそうですね。テスト駆動開発の準備では、実際にテスト駆動開発をやりたい場合、どうすればいいか。実際のツールを確認しつつ、見てみましょう。標準のテスト実行環境です。実際にテストしてみよう実際にテスト駆動開発を始めてみようとした場合ですが、色々な準備が必要です。設定をする必要があります。設定の追加は、ほとんどの場合、アセットバンドルの再構築が必要になると思いますので、ご注意。こちらのサイトは、初期設定のやり方から、詳しく記載されていますので、かなり参考になります。資料で設計を行うのであれば、やはり、テスト駆動開発は導入するべきだと思います。テストも含めての事例であります。今後同じようにマネされる方がいらっしゃいましたら、これが少しでも参加になれば幸いです。笑この記事を書いた人ねこ渋谷区在住のエンジニア。記事のリクエストや要望などはツイッターで受け付けています。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。