背景

もともとRailsとRubyとJSを書いていた人間だったが、最近はPHPとGoをよく書くので、それっぽい記事を書いておこうと思った。

今回はConstructor Injectionを用いてテストしやすい、Mockに差し替えしやすい、なんか読みやすいコードを書くため小技を残す。

前提

PHPは7.2を期待して記述しています。あるいは、PHPDocによる型の宣言をサポートされているIDEや、それに準ずる環境を期待して記述しています。

この記事に存在しない要素

DI ツールを利用した記述方法

Constructor Injection ?

Dependency Injection

Dependency Injection を実装する手法の一つです。他には Properties Injection(Setter Injection) 、 Interface Injection といった実装手法があるようです。

Dependency injection - Wikipedia

Dependency Injection(以下DI) は日本語文献では「依存性の注入」と記述されることが多く、あるオブジェクトが依存する振る舞いや知識（これらを表現するものとしてオブジェクトがありますね）を外部から注入することによって、SOLID原則に対して容易に準ずる事ができるコードを記述できるようになります。

依存性の注入 - Wikipedia

Wikipedia日本語版いわく、https://ja.wikipedia.org/wiki/%E4%BE%9D%E5%AD%98%E6%80%A7%E3%81%AE%E6%B3%A8%E5%85%A5

結合度の低下によるコンポーネント化の促進
単体テストの効率化
特定のフレームワークへの依存度低下

の効果があるとされています。今回は特に単体テストの効率化について記述します。

Constructor Injection

ではDIにおける Constructor Injection とは何でしょうか。その名の通り、Constructorで依存関係を定義、注入する手法です。

PHPでは、簡単に言えば以下のようなものです。

<?php

class K {
  private $dependency;
  public function __constructor(Dependency $dependency)
  {
    $this->dependency = $dependency;
  }
}

簡単ですね。実際には、 private $dependency のプロパティにPHPDocで型宣言をしましょう。また、PHP7.4 で Typed Properties がくるっぽいので、わくわくしましょう。

PHP: rfc:typed_properties_v2

より正しいDI

より高度に設計されたDIでは 、 Dependency といった実Classに依存するのではなく、 DependencyInterface や AbstractDependency といった抽象に依存するほうがよりよいとされています。

理由は、「結合度の低下によるコンポーネント化の促進」に対してより効果的に作用するためです。

また、この __constructor の定義自体も Interface に切り出すことで、より実Class間の依存度は下がり、上記効果が高まりますが、

僕はInterfaceがはじめからうまく作成できると思っていない ので、実クラス同士で Constructor Injection くらいが身体にあっています。

本当に凝集度を考慮するくらいに複雑になったら、その時にInterfaceの存在に思いを馳せるとより適切なInterfaceがそこに見いだせるでしょう。

実際に書く

サンプルコード

基本的には以下の点だけを気にしてコードを書いていきます。 1. 「処理」を知っているObjectは初期化時にのみ渡す 2. 「処理」への引数の受け渡しと、引数に依存する振る舞いのみ記述する

サンプルコードとして、Articleの情報を受け取って、Tweetを返却するクラスを考えてみます。

<?php
// 簡単のために、 namespace を省略して、 use も省略しています。

class TweetTextBuilder{
  $article_formatter;
  $user_repository;
  $tweet_validator;
  $tweet_builder;
  
  public function __constructor(ArticleFormatter $article_formatter, UserRepository $user_repository, TweetValidator $tweet_validator, TweetBuilder)
  {
    $this->article_formatter = $article_formatter;
    $this->user_repository = $user_repository;
    $this->tweet_validator = $tweet_validator;
    $this->tweet_builder = $tweet_builder;
  }

  public function build(Article $article): Tweet
  {
    $user = $this->user_repository->findById($article->getId());
    $text = $this->article_formatter->format($article, $user);
    $validate_result = $this->tweet_validator->validate($text);

    if (!$validate_result->isValid()) {
      throw new ValidateError($validate_result->getMessage()) // 140 文字overかもしれないし、User不正な空文字かもしれないし
    }

    // 本当は TwitterUser が別で存在すると思うんだけど、とりあえず同じContextのUserを共有することにした
    return $this->tweet_builder->build($user, $text)
  }
}

長い？長いですね。とくに Constructor の引数が長いですね。でも現代のIDEやエディタを利用している我々は補完があるので、この程度の長さは特に気になりませんね（本当ですか？）さて、ではこのコードのテストコードを書いてみましょう。

<?php

// これまた PHP Unit の use を省略しています。Extendも省略
class TweetTextBuilderTest {
  public function testBuildWhenErrorOnTweetValidator() {
    $article_formatter = $this->createMock(ArticleFormatter::class);
    $user_repository = $this->createMock(UserRepository::class);
    $tweet_validator = $this->createMock(TweetValidator::class);
    $tweet_builder = $this->createMock(TweetBuilder::class);

    $user = new User();
    $validate_result = new ValidationResult(false, '140文字オーバーです');

    $article_formatter->expects($this->once())->method('format')->willReturn('example');
    $user_repository->expects($this->once())->method('findById')->willReturn($user);
    $tweet_validator->expects($this->once())->method('validate')->willReturn($validate_result);
    // validate_result が error なので、このオブジェクトのこのメソッドは呼ばれないことを確認する。
    $tweet_builder->expects($this->exactly(0))->method('build');

    $tweet_text_builder = new TweetTextBuilder($article_formatter, $user_repository, $tweet_validator, $tweet_builder);

    $article = new Article();
    $tweet_text_builder->build($article);
  }
}

mock ばっかり？そうですね。ただ、このクラスのこのメソッドについてテストしたい要素は2つです。 1. tweet_validator の返却値のオブジェクトの isValid() メソッドが true だった場合 - すべての依存先Classの該当メソッドが呼び出されること。 - よりちゃんとやるなら、各 mock の willReturn を異なる mock の with() に指定することで、「このメソッドの返却値がこのメソッドの引数になること」を宣言し、テストしてもよい 2. 上記メソッドが false だった場合 - TweetBuilder のオブジェクトのメソッドがコールされないこと - 1. の下の要素もやってもよい

ただし

ただし、各依存先の各メソッドが適切にテストされていることを期待しているので、そうでなければこの手法も意味がないです。「このClass（このObject）は何をする（何を知っている）のですか？」という問いに「〜をします（を知っています）」と一言で答えられるまでに要素を分解していき、その小さい部品ごとにテストを書いて、それを結合するクラスがいる、そういう状態を目指しています。

メリット

テストしやすい。特に Repository への直接依存しないことによってもちろん実データを用意する必要がない。(いろんな実装があるとは思うけどとりあえず)
条件分岐も mock の willReturn の返却値をいじればしゅっと書ける
各依存先Classをテストすれば容易にカバレッジもあげられるし、各々の仕様が変更されても（たとえばArticleFormatterは文頭100文字だけをSplitするだけだったが、「最初は自己紹介が定型文なので、本文はじまりから100文字だけを取得するようにする」みたいな仕様変更があっても、このClassや他のメソッドの振る舞いは変更しないで良い（事が多い）

デメリット

テストが長く、同じようなことを何度も記述しなければならない
mock の生成を短くしても、しょうがない。
DateProvider を利用することによって、パターンは別で記述することもデキるが、 expects を利用したいので、悩ましいといえば悩ましい。
初見ではわかりにくい
なんでこんなことしてるのかがわかりにくい。

終わりに

テストがしやすい、よく分離されているコードは問題がわかっても調査するポイントが絞りやすく、また仕様変更に対しても依存先のObjectに閉じたり、そもそもこのクラスまるごと捨てるかの二択になりやすい。

とはいえ、「常に140文字をオーバーするFormat結果しか帰ってこない」状態になったりしたら、常に失敗するのはそうなので、分離されていることに対して忌避感を持つことも十分にわかる。

いい感じの塩梅を目指し、常に改善するポイントを探していくのがソフトウェア開発における楽しいポイントでもあるといいなぁと思う。

Lumped tweets

Just marks

Constructor Injection でやるテストしやすいPHP

背景

前提