Magento Cafe Plus #12

最近のMagento

Magento 2 サンプルデータ

Magento2 Docker

翻訳プロジェクト

デザインカスタマイズのレシピ

レイアウト XML再入門

レイアウト XML で使えるタグタグ名 親要素 子要素layout なし ハンドルタグハンドルタグ layout block

referenceremove

block ハンドルタグblock

blockaction

action block パラメータタグreference ハンドルタグ

blockblockaction

remove ハンドルタグupdate ハンドルタグパラメータタグ actionパラメータタグ パラメータタグ

タグで使える属性タグ名 属性名ハンドルタグ translate

moduleblock name

typetemplateoutputasbefore / after

action methodifconfigmoduletranslate

reference name

remove name

パラメータタグ helper

update handle

name と as の違い• as 属性の値はテンプレート上で呼び出すときにのみ使用。レイアウト XML で as 属性の値を指定しても無駄。• name 属性は as 属性がないときは as 属性の代わりをする。レイアウト XML 上で要素を指定する場合は常に name 属性の値を指定する。

パラメータタグの helper 属性• helper 属性を与えることで、 Helper クラスのメソッドに処理を委譲することができる– 翻訳させたり、変数によるテンプレートや URL 切り替えなどができる

• パラメータタグの子要素で更にパラメータタグを定義することで、 Helper のメソッドに与えるパラメータを定義できる

例 1

<reference name="customer_account_navigation"> <action method="addLink" translate="label" module="myext" ifconfig="myext/mygroup/myparam"> <name helper="myext/label/getLinkLabel"/> <path>myext/page</path> <label helper="myext/label/getLinkLabel"/> </action></reference>

例 2

<customer_account_login> <reference name="head"> <action method="setKeywords"> <keywords helper="core/data/__"> <value>Some keywords</value> </keywords> </action> </reference></customer_account_login>

CSS/JS の削除• あるページの CSS や JS が邪魔なんだけど・・・• あるページに付けたい jQuery のプラグインがバージョンあわなくて (ry

• なんてときに便利な技

例<reference name="head"> <action method="removeItem"><type>skin_css</type><name>css/styles.css</name><params/></action>

<action method="addItem"><type>skin_css</type><name>css/custom.css</name></action></reference>

テーマの継承関係• 1.9 まで– 現在テーマ → 現在テーマの default → base/default

• 1.9 から– 現在テーマ → 親テーマ → base/default– etc/theme.xml をうまく使うこと

facade

• Mage_Core_Block_Template_Facade

• append で既に定義されている別ブロックを自分の子ブロックとして定義できる• 商品ページで多用– 他のページではつかってない・・・

テンプレートとブロックのあれこれ

js をフッターに持ってきたい• page/html_head を使う– 別の name で定義して、テンプレートも別指定にする

• Mage_Page_Block_Html_Head には JS/CSS タグを生成する機能がある• ただし、全部をフッターに持ってこれないので注意– Translator とかは無理だった気が・・・

テンプレートがなくても出力したい• Mage_Core_Block_Text_List や

Mage_Core_Block_Text_Tag を使う• あるいは独自でなにか実装してしまう

特定のページだけテーマを変えたい• CMS/ カテゴリ / 商品であれば、設定で対処可能• ではそれ以外のページの場合はどうする？

フォールバックをうまく使う• マークアップをできるだけ共通化する– CSS と JS だけで出来るだけ見た目を調整する

• レイアウト XML を使って、部分的にテンプレートや CSS/JS を入れ替える• つまりは変更点を局所化し、メンテしやすくする

静的ブロックの埋め込み• 方法は 2 通り– レイアウト XML であらかじめ定義しておく– PHP コードをテンプレート上で直接書く

• 静的ブロックを 1 個処理するのに最低でも 2 〜3 本の SQL が「アクセスごとに走る」点に注意– 便利だからと闇雲に埋めるのは NG– ブロックキャッシュをうまく使わないとサイトが遅くなる– またはフルページキャッシュの導入

商用テーマの功罪• 商用テーマは便利な機能がワンパッケージになっている– 素早くサイトを立ち上げたい時には大変便利– ある程度カスタマイズしてあるので、要件に合うときはすごく楽

• 反面、テーマ乗り換えの時が大変– テーマ同士に含まれる機能の競合– 機能の移植・統合・再実装・・・などなど

ユニットテスト〜M1とM2〜

Magento とユニットテスト• そもそも Magento1 の開発段階ではユニットテストの概念がなかった（ phpunit などは既にあったのだが・・・）• サードパーティ実装の EcomDev_PHPUnit や公式の Test Automation Framework （ TAF ）を使ってユニットテストをやるケースが続いていた。（ただし、 TAF は対応が遅かった）

1.9.2.0 での追加• 公式の MTF （ Magento Testing Framework ）の同梱– ただし、 1.9.2.0 だけの話

• とはいえ公式にユニットテストのフレームワークが付属することは喜ばしい

Magento2 では？• そもそもの前提としてユニットテストだけでなく、パフォーマンステストやマイグレーションテストまで付属• テストコードを付属させるのが「当然」の流れに• Magento Connect に公開するためには、テストコードを付属させることが絶対条件

ユニットテストの実際

EcomDev_PHPUnit の場合• EcomDev_PHPUnit をまずインストールする– PHPunit ももちろん必要

• エクステンションの config.xml に追記する• ドキュメントを読みながらテストコードをコツコツ書く– Model だけじゃなく、 Block や Controller のテストもできるので、色々試すと Good

config.xml

<phpunit> <suite> <modules> <My_Extension /> </modules> </suite></phpunit>

テストケース• app/code/ コードプール /My/Extension/Testに配置する• テストする単位でファイルを分ける• もっと詳しく知りたい場合は、

http://www.ecomdev.org/wp-content/uploads/2011/05/EcomDev_PHPUnit-0.2.0-Manual.pdf を

テストケースの例class My_Exension_Test_Model_Customer extends EcomDev_PHPUnit_Test_Case{ public function setUp(){} public function tearDown(){} public function testSomething(){}}

Magento2 の場合• そもそもユニットテスト機能はフレームワークに統合されている• もちろんベースは PHPUnit なので、 PHPUnit の経験がある人の知識は無駄にならない• テストケースは、 Myextension/Test/Unit に置く• もちろん MTF も利用可能

作り方• app/code/My/Extension/Test/Unit 以下にコードを置く• namespace を定義し、 PHPUnit_Framework_TestCase を継承する• あとは PHPUnit のお作法通り書いていく

Magento Testing Framework の場合• 1.9.2 なら標準でついてくる– https://github.com/magento/mtf

• 基本的に、 Test Automation Framework の改良版• Selenium と連携してテストを行う、と言うもの• 正直、フロントエンドのテストは辛い。主にバックエンドのテスト向け

フロントエンドのテストが難しい理由• マークアップに差がありすぎる– デフォルトのマークアップで調整しきれればよいが、通常何かしらマークアップに変更が入っている

• テストケースの変更が多い– Web サイトなのだからこれは当たりまえ

• 決済系のテストをどうするか、はそれなりに課題

そもそも論• ユニットテストの担当範囲をどこまでにするか？– Model/Block/Helper レベル？– Controller までやるべき？

• Magento2 的解釈では、– Model/Block/Helper と Controller の一部→　ユニットテスト– それ以外→ MTF, api-functional, integration, performance などの専用テストツールを用いる