2018-12-29

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

背景

もともと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結果しか帰ってこない」状態になったりしたら、常に失敗するのはそうなので、分離されていることに対して忌避感を持つことも十分にわかる。

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

2018-06-15

Twigを外部Templateファイル無しで使う

php twig

この記事で分かること

Twigの亜空間殺法(嘘)

背景

自前でTemplateEngineみたいなことをしようとしたときに、そもそもPHPでTwig使ってるんだからそれ使えば良くない？ってなったので、調べた。結論を言うとやりたいことより複雑性が高かったので今回採用はしなかった。

Twig はこちら

Twig for Developers - Documentation - Twig - The flexible, fast, and secure PHP template engine

コード

なんかPHPのシンタックスハイライト効いてるのか効いてないのかわからん……

use Twig_Loader_Array;
use Twig_Environment;

$targetTxt = "You are {{ replaceText }} ?";

$loader = new Twig_Loader_Array(['index.html' => $targetText]);
$twig = new Twig_Environment($loader);
try {
    $res = $twig->render('index.html', ['replaceText' => 'hogehogewww']);
} catch(Exception $e) {
    var_dump($e);
}

$res; 
// "You are hogehogewww ?"

Twig_Loader_Array でインメモリに index.html をKeyとしてTemplateを束縛。束縛したTempleteをRenderするときに連想配列で置換したい内容を挿入。

なるほどなぁ。

2018-05-31

マネーフォワードを退職した

この記事でわかること

とくにないです

背景

退職した。退職エントリだがレギュレーションとかを遵守した（つもりになった）やつは社内向けに書いた。興味がある人はマネーフォワードへ入社してみてください。esaに多分残ってます。残ってるよね……？

内容

5/31 が退職日です。 5/25 が最終出社日です。

間がなかったのは有給がもうなかったからです。

6/1 からは新しい場所で働き始めます。

MFで学んだこと、知ったこと、なるほどなぁと思ったこと一覧です

お金に対する忌避感を拭えた話
真っ向から技術力で殴ることの大切さと、難しさ
現金はある程度あればよくて、ほかはガンガン投資に回すとよさそうなこと（投機じゃないよ）
職業お金持ちは職業お金持ちなんだなぁということ
田町という街
事業の大切さ
本音と建前と社内と社外と……そんな様々な境界面にこそなにか大切なことがありそうだなぁという軽い気持ち
情報が閲覧できることの大切さ
自由と責任
お金は大切

おわりに

おすすめのETF教えてください

2018-04-24

回文かどうかを判定するやつを作ってた

ポエム

この記事でわかること

github.com

背景

github.com

↑がすごいいいなーってなった。回文についてもなんか雰囲気判定したくなった。

なので作った。

まとめ

よかった！おわり！きもちぃー！ふぅー！

2018-03-12

zshrcに書いてある適当な関数を紹介する

ポエム

この記事でわかること

特になし

git で upstream と merge する関数

なんで？

fork branch 運用をしていると origin は haito/repo で、 upstream が original/repo になる。定期的に original/repo から持ってこないとたいへんなことになる。

関数

function upstream_update() {
    branch=$1
    git add . || git commit -m "upstream update cunked!" > /dev/null
    git checkout $branch > /dev/null
    echo "fetching upstream..."
    git fetch upstream
    echo "merging upstream..."
    git merge "upstream/${branch}"
}
alias uu="upstream_update"

これを uu develop とすると、 current branch は適当に commit して、 develop に checkout して、upstream の develop と merge する。

小文字英数字の uuid を発行する

なんで？

ruby の SecureRandom.uuid と振る舞いを合わせた uuidgen

関数

function lower_uuid_gen() {
    tr '[A-Z]' '[a-z]' <<< `uuidgen`
}

このまま実行するだけ

雑にメモ帳を開く

なんで？

わからない……俺たちは terminal の呪縛から解き放たれた……はずなんだ……

関数

function je() {
    filename=$1

    e /tmp/$filename
}

junk emacs の略だと思う。いろんなOneNoteとか、BearとかEverNoteとかいろいろ試したけど、何故か無理なのでこうなった。

2018-02-16

Vue + slick (jquery plugin) でハマった話

この記事でわかること

vue + jquery の悪魔合体は程々にしよう

背景

気持ちとしてはこういうことをしたかった。

vue のシンタックスハイライトが効かなかったので別々で……

<template>
  <div class='cards is-slick'>
    <div class='card' v-for="element in elements">
      <element></element>
    </div>
  </div>
</template>

export default Vue.extend({
  data() {
    return {
      elements: []
    }
  },
  methods: {
    async getElements(){ HTTP.get('/api/elements').map(x => Element.new(x)) }
  },
  // mounted か created かはともかく
  async created() {
    this.elements = await getElements()
  }
})

雰囲気はわかってくれると思う。雰囲気はね。で、問題は <div class='cards is-slick'> を slick でカルーセルにしたい。

なので、とりあえずこうやって見る

// ...
mounted() {
  $('.is-slick').slick()
}

これは動かない。何故かと言うと、 slick はそのイベントが発火した時点のdivしか補足できず、新たに読み込まれた div はカルーセルの対象外になってしまうためだ。つまり

  <div class='cards is-slick'>
    <div class='card' v-for="element in elements">
    </div>
  </div>

この状態で slick() を発火しても意味がないということだ。これをどうにかしたい。

ずさんな解決方法

つまり、全てのElementが用意された時点で slick() を発火してやれば良い。

export default Vue.extend({
  data() {
    return {
      elements: [],
      isSlicked: false
    }
  },
  methods: {
    async getElements(){ 
      await HTTP.get('/api/elements').map(x => Element.new(x)) 
    }
  },
  async created() {
    this.elements = await getElements()
  },
  watch: {
    elements(vals, oldVals) {
      if (!this.isSlicked) return;

      $('.is-slick').slick('unslick')
      this.isSlicked = false
    }
  }
  updated() {
    if(!this.isSliced) {
      $('.is-slick').slick()
    }
/**  2018/02/16 11時05分 更新
    this.$nextTick(() => {
      try {
        // 既に slick() してあるElementに対してもう一度発火すると落ちる。
        // 逆に、まだ slick() していないElementに対して `unslick` を発火しても落ちる。
        // ほんに〜〜〜〜〜？？？？？？？？？
        $('.is-slick').slick('unslick')
      } catch(_){ 
      } finally {
        $('.is-slick').slick()
      }
*/
    })
  }
})

updated で $nextTick() を使うと全てのRenderが完了してから呼ばれる。これで解決したけど、ずさんすぎる気がする。たぶんComponentのライフサイクルの設計が間違っているんだと思う。

誰か良さげな回避策を教えて……ください……

そもそも slick を利用しないという選択
カルーセルくらい自前で作れるだろ感
etc...

2018-01-16

rails で cookies を使ったテストをrequest, feature spec ではない書き方でテストするための方法が知りたい

Rails Rspec Ruby

この記事でわかること

request spec や feature spec ではない、 cookies だけをどうにかして取り出してテストを書きたいフレンズが、テストを書けるといいなぁって思えるようになる。ただし、厳密には違う。違うんだ……どうしたらいんだ……教えてくれ…………（ほんとう？

背景

例えば以下のようなコードでテストを書きたかった

# app/models/state.rb # めっちゃだめなクラス名だな……
class State
  class CookiesAdapter
    def initialize(cookies)
      @cookies = cookies
    end

    def transition!(key)
      @cookies['state_transition'] = { value: key }
    end

    def in?(key)
      @cookies['state_transition'] = 
    end
  end

  def initialize(adapter)
    @adapter = adapter
  end
  
  def transition!(key)
    @adapter.transition!(key)
  end

  def in?(key)
    @adapter.in?(key)
  end
end

class HogeController
  def show
    @state = State.new(State::CookiesAdapter.new(cookies))
  end
  # ... 
end

State インスタンスの振る舞いは、実際には hogeAdapter の同名のメソッドを呼ぶことで、上の実装では CookiesAdapter しかないが、まぁRedisなりなんなりのAdapterがあればいい感じに振る舞いを分離できて幸せそう。 AdapterPattern のようなナニだ。

で、Cookiesを使いたい時に、 Rails では ActionDispatch::Cookies に実装*1があり、他にもあるが一番わかり易いのが ActionDispatch::Request#cookies_jar で*2、 Cookies::CookiesJar.build 経由で cookies_jar を作って、その alias として cookies 名*3でのアクセスが実現できている。

困ること

Cookies を直接インスタンス化するために必要なパラメーターがわからん（調べればいいんですが）
request spec として、リクエストが透けた形で↑のモデルのテストを書きたくない
feature spec として以下略
ActionController のインスタンス化でもいいけど、なんかもう少し上手いやつないかなぁ

ということでテストの書き方二種

二種？というのは、rails のバージョンで異なるため。古いバージョンとかは知らない。4.2は古いっていうのは、はいそうですね。

rails 4.2

RSpec.describe State::CookiesAdapter do
  let(:cookies) { ActionDispatch::Request.new({}).cookies }

え、なにそれ辛い。辛いというか、とくに new({}) あたりが、「本当にそうなのか」がワカラナイ。一応、 Rails.application.env_config でよいっぽいというStackOverflowの気持ちを見ることができるが、ほんと〜？となる。

unit testing - Setup cookie.signed in Rails 5 controller integration tests - Stack Overflow

rails 5

RSpec.describe State::CookiesAdapter do
  let(:cookies) { ActionDispatch::Request.empty.cookie_jar }

https://github.com/rails/rails/blob/master/actionpack/test/dispatch/cookies_test.rb#L12 rails が自らのテスト↑で @request を Request.empty で作成してそこから cookie_jar を取ってる。( 厳密には cookies_jar )

なんか結局イマイチだけど、まぁ rails がそうやってるなら、まぁいいんじゃないかな？となる。

おわりに

rails5 を使おう
そうでないなら ActionDispatch::Request.new({}).cookie_jar で一応取れる。ほんと〜？

*1:https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/middleware/cookies.rb#L170

*2:https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/middleware/cookies.rb#L11

*3:https://github.com/rails/rails/blob/master/actionpack/lib/action_controller/metal/cookies.rb#L13