Symfony Meetup Tokyo での Extract Till You Drop の写経
PHPメンターズ道場生の @ganchiku です。よろしくお願いします。 はじめに10月4日 Engine Yard 東京オフィスにて、Symfony Meetup が開催され、14人ほどの参加者がありました。そこでのテーマは、Symfony Live London 2013 のセッションのうち Mathias Verraes さんの Extract Till You Drop（極限まで抽出せよ）のコードを真似てみよう、というものでした。Extract Till You Drop という言葉は、Uncle Bob ことロバート・マーチン氏の引用になります。 さて、Mathias さんのライブコーディングは、 YouTube にアップロードされており、その過程を PHP メンターズの後藤さんが説明しながら、一緒に写経を行いました。 http://verraes.net/2013/09/ex
モックで置き換えの境界線
以前のSymfony勉強会の折にユニットテストとモックの話をさせていただいたのですが、その時に@cakephperさんから次のような意見を頂いていました。 APIを信用して基本Mockでという話、API側の仕様変更を常にウォッチしてないといけないのでフレームワークのアップデートとか大変なんじゃないのかなと思ったんだけど、そこんとこまだ消化できてない twitter - @cakephper まず最初に回答としては「APIが変わるのであれば概ねそのとおり」となります。しかし、これはモックを使うかどうかには関係ありません。ソフトウェアはフレームワークやライブラリ等サードパーティコードの仕様変更に常に影響を受けます。ここで、議論の前提を共有しておく必要があるでしょう。 ユニットテストとファンクショナルテストの使い分け。どちらが書きやすいのか。ユニットテストでテストしたい箇所はどこか。前提として、
BehatでURLをページ名で扱うには
Behat 1系では、Webサイト内のページへのアクセスに対して、URLを直接フィーチャーに記述するのではなく、ページ名をつけて抽象化できるようになっていました。フィーチャーの可読性や抽象度の統一の面で優れた方法です。URLのを直接フィーチャーに記述すると、たとえば次のようになります。 シナリオ: 会員登録申込 前提 "/" を表示している URLのかわりにページ名を用いると、次のようになります。 シナリオ: 会員登録申込 前提 "トップページ" を表示している Behat 2系では直接URLを記述する方法しかサポートされておらず、ページ名を利用するには、多少の準備が必要です。 依存ライブラリ準備Behat/CommonContextscomposerでインストールしている場合は、behat/common-contextsを以下のように追加します。 { "require": { "beha
Pimpleでシンプルに正しくDIを理解する
オブジェクト指向でソフトウェアを実装していると、オブジェクトの生成に一連の手続きが必要なものがでてきます。このような生成に関する手続きがあちこちのソースコードへ散在すると、望ましくない状況になることは想像に難くないでしょう。この問題に対処するために、Simple FactoryやFactory Methodといったデザインパターンがあり、オブジェクトの生成に関する手続きや関連オブジェクトも含めたオブジェクトの構成（オブジェクトコンストラクション）に関する知識は1箇所にまとめるということが定石となっています。 しかし、単にファクトリーを導入するだけだと、オブジェクトの構成処理は分離・隠蔽できても、利用オブジェクトがファクトリー自体に依存してしまうことになります。このような試行錯誤の歴史から登場したのがDependency Injection(依存性の注入)パターンです。Dependency
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
