BEAR.Sunday meetup #3 in Osaka 参加レポート
プログラミング道場生kumamidoriです。 PHPフレームワークの１つに、「BEAR.Sunday」があるのをご存知でしょうか。 リソース指向のOSSフレームワークで、郡山さん（@koriym）によって開発されています。 去年イギリスで行われたカンファレンス、「PHPNW2013」では、BEAR.Sundayのアーキテクチャを紹介するセッションがありました。 私は以前、旧バージョンにあたる「BEAR.Saturday」の方を仕事で使っていました。新しいBEAR.Sundayついては、初学者の状態で、さわる機会もあまりなかったのですが、気になっていました。2013年7月には、BEAR.Sunday meetup #2の主催をさせて頂いたこともありました。 そのようないきさつがあり、4月7日、BEAR.Sunday meetup #3 in Osakaを開催することになりました。 郡山さん
Beyond MVC
PHP Advent Calendar 2013 - 6日目 昨日は@fivestrさんのComposerを使った簡単Travis CI設定でした。 TL;DR オブジェクト指向/MVCでうまく捉えきれていなかったものは何なのか？MVCから続くソフトウェアアーキテクチャーの「その先」は何なのか？Reenskaug博士を知っていますか？ WikipediaによればReenskaug博士は1930年生まれ。MVCという概念が世の中に送り出された論文『MODELS - VIEWS - CONTROLLERS (pdf)』は1979年ですから、49歳の時ということになります。1960年からソフトウェアを書き始め、1973年からオブジェクト指向でソフトウェアを開発しており、現在でも現役でソフトウェアの世界にいらっしゃいます（ex 2009年の講演）。「プログラマ歴42年 (* Clean Coder
状態ではなく、振る舞いをモックせよ
TL;DR GOOS本『実践テスト駆動開発』で触れられている「ロールをモックせよ」について、違った角度で解説ドメインモデルを豊かにすることでコードがシンプルになる例Mock Behaviors, Not Statesユニットテストを記述する際、テスト対象のオブジェクトが利用しているオブジェクト（依存オブジェクト、隣接オブジェクト）はモックオブジェクトにして、テストしたい状況をテストコード側からコントロールします。しかし、闇雲にモックを使ってテストを記述すれば良いわけではありません。今回は、モックが有効に機能するテストとはどういったものなのかを解説します。 サンプルコード簡単なサンプルで説明します。Extract Till You Dropのモデルと近いものを使います。グループ、メンバー、およびグループリポジトリがあります。グループオブジェクトはインメモリでは所属メンバーの情報を保持しておら
モックで置き換えの境界線
以前のSymfony勉強会の折にユニットテストとモックの話をさせていただいたのですが、その時に@cakephperさんから次のような意見を頂いていました。 APIを信用して基本Mockでという話、API側の仕様変更を常にウォッチしてないといけないのでフレームワークのアップデートとか大変なんじゃないのかなと思ったんだけど、そこんとこまだ消化できてない twitter - @cakephper まず最初に回答としては「APIが変わるのであれば概ねそのとおり」となります。しかし、これはモックを使うかどうかには関係ありません。ソフトウェアはフレームワークやライブラリ等サードパーティコードの仕様変更に常に影響を受けます。ここで、議論の前提を共有しておく必要があるでしょう。 ユニットテストとファンクショナルテストの使い分け。どちらが書きやすいのか。ユニットテストでテストしたい箇所はどこか。前提として、
DDDのリポジトリの外部依存とオブジェクト指向の原則の適用について
DDDのリポジトリがORMコンポーネントへ依存することの是非について、オブジェクト指向の原則の面から解説します。 リポジトリ（repository）とは、収納場所・倉庫・貯蔵庫を表す言葉です。 DDD（ドメイン駆動設計）では、リポジトリはモデル駆動設計でドメインをモデリングする際のビルディングブロックの1つになっています。ビルディングブロックとは基本構成要素のことで、ドメインをモデリングする際の基本部品として使います。 DDDのリポジトリの役目は、ドメインレイヤーのオブジェクトから永続化レイヤーを隠蔽することです。リポジトリ＝"エンティティの貯蔵庫"という抽象化されたオブジェクトを持ち込み、ドメインレイヤーの内部では貯蔵庫からエンティティを取り出すように設計・実装します。 構築するシステム（ここでは何か１つのシステムのみをイメージしてください）においてアーキテクチャが決定すると、その段階で
時計オブジェクト（ドメインクロック）を導入してテスト容易性と意図性を高める
現在の時刻を扱うロジックがアプリケーションコードに含まれるのは珍しいことではありませんが、これらのロジックのテストは簡単ではありません。以下のコードを見てみましょう。 <?php ... class OrderService { ... public function order(Order $order) { $currentHour = (integer) (new \DateTime())->format('H'); if ($currentHour >= 10 && $currentHour < 21) { ... } else { throw new OrderException('ご注文は午前10時から午後9時まで！'); } } ... 実際の現在の時刻に依存せずにif文の条件をテストする1つの方法は、DataTimeオブジェクトの生成部分をメソッドとして抽出し、そのメソッド
関数・定数のラッパーオブジェクト（レガシープロキシー）を導入してテスト容易性を高める
PHPユーザーであれば、PHPが標準で持つ多くの内部（ビルトイン）関数や定数には日常的にお世話になっていることでしょう。これらの内部関数・定数はPHPの便利さの象徴といえます。しかし、内部関数や定数の使用はテストのしやすさを低下させる原因となります。以下のコードを見てみましょう。 <?php ... class CollectingType { protected $type; protected $expectedSuperTypes = array(); ... public function isTest() { if (in_array($this->type, $this->expectedSuperTypes)) { return false; } else { foreach ($this->expectedSuperTypes as $expectedSuperType)
Zend\Diを使ったDIの自動ワイヤリング
「Pimpleでシンプルに正しくDIを理解する」の記事では、シンプルなDIコンテナPimpleにオブジェクトの依存関係の知識を集約する方法について解説しました。Pimpleの場合はサービスオブジェクトのファクトリーとして機能する無名関数の中に依存オブジェクトを記述しました。このように、実際に利用する依存オブジェクトを決めることをワイヤリングと呼びます。 今回は、ほぼ同一のオブジェクトモデルに対して、Zend Framework 2.0のDIライブラリ（Zend\Di）を使うように置き換えてみます。一般的にDIを扱う場合、依存関係の定義とワイヤリングのために何らかのコード―これは何らかの設定言語だったりプログラミング言語だったりします―を記述しなければならず、ある程度の規模以上のモデルクラス群をDIコンテナで管理する場合、定義のコーディング量がばかにならくなってきます。しかし、型を持ったプロ
Pimpleでシンプルに正しくDIを理解する
オブジェクト指向でソフトウェアを実装していると、オブジェクトの生成に一連の手続きが必要なものがでてきます。このような生成に関する手続きがあちこちのソースコードへ散在すると、望ましくない状況になることは想像に難くないでしょう。この問題に対処するために、Simple FactoryやFactory Methodといったデザインパターンがあり、オブジェクトの生成に関する手続きや関連オブジェクトも含めたオブジェクトの構成（オブジェクトコンストラクション）に関する知識は1箇所にまとめるということが定石となっています。 しかし、単にファクトリーを導入するだけだと、オブジェクトの構成処理は分離・隠蔽できても、利用オブジェクトがファクトリー自体に依存してしまうことになります。このような試行錯誤の歴史から登場したのがDependency Injection(依存性の注入)パターンです。Dependency
PHPカンファレンス関西2012のLTでモックの使い方について話しました
2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。 セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。 今回のテーマはマルチパラダイムデザイン（Multi-Paradigm Design: MPD）の中核を成し、DCI / リーンアーキテクチャ（Lean Architecture）とも深く関係する 共通性／可変性分析 でした。 レポートは @smori1983 が担当させていただきます。 当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントに
Practical Symfony #6: Symfony2の@apiアノテーションによる後方互換性の維持管理
この記事はSymfony Advent Calendar JP 2011の24日目の記事です。 速いペースでマイナーバージョンアップされるSymfony2Symfony2は、2011年7月に2.0がリリースされて以降、概ね月に1回のペースでメンテナンスリリースをしています。私自身が開発に携わっている案件でも、何度かこのようなメンテナンスリリースによるSymfony2本体のバージョンアップを行いましたが、直接的な問題はほぼ発生していません。フレームワークの更新というと、マイナーバージョンアップでさえ事前に変更点をしっかり調査し、適用しても問題がないという調査・判断が必要でした。Symfony2でももちろん事前に変更内容を調査することは必要ですが、Symfony2側で後方互換性が維持されるルールが導入されており、上手く機能しているようです。 この「後方互換性を維持するルール」の中心となるのが「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
