カスタム投稿タイプのデフォルトウィジェットブロック一式が詰まったWordPressプラグイン「Custom Post Type Widget Blocks」をリリースしました

カスタム投稿タイプで活用できるデフォルトウィジェットブロック 7 点が詰まった WordPressプラグイン「Custom Post Type Widget Blocks」を作りました。

WordPressプラグイン「Custom Post Type Widget Blocks」は、以前つくったウィジェット版の WordPressプラグイン「Custom Post Type Widgets」のブロックエディタ版です。

WordPress 5.0 から標準エディタがブロックエディタになりました。それに伴い、ウィジェットはブロックエディタに統合されていくことを見越して、ブロックの作り方をちょこちょこ学びつつ作ってみました。

機能は、Custom Post Type や Taxonomy で絞り込みができる以外は、標準のウィジェットブロックとほぼ同じです。
ある程度安定した状態になれば、将来的に機能を追加して拡張していこうかと思います。

是非ブロックエディタで活用してみてくださいね。

WordPressテーマ「Foresight」がレビューを経て wordpress.org 公式ディレクトリに掲載されました

WordPressテーマ「Foresight」が wordpress.org 公式ディレクトリに掲載されました。

WordPressテーマ「Foresight」は、公式ディレクトリ登録を目指していたので、テーマ開発に取り組んで目標の一つを達成できて一段落つきました。これからもテーマの改良を続けてブロックエディタの活用を充実させたり、いろいろ研究開発を行っていきたいですね。

ということで、公式ディレクトリ登録を行う上で欠かせないテーマレビューはどのようなものか。2ヶ月ほどやり取りしていたレビューの所感を綴ってみたと思います。

WordPressテーマ「Foresight」の詳細や作ったときの感想は、以下を見てください。

テーマレビュー経緯

テーマの登録申請を2019年11月25日にしました。
その時のテーマレビュー待ち200余り。
とりあえず気ままに待つことに。

待つこと3ヶ月ほど。
2020年2月13日にレビューアさんが付いてくれました。
途中新型コロナウイルスの大流行で滞りなくレビューが進むのが心配していましたが、普通にレビューが進んでいきました。こういうときにコミュニティが機能しているありがたさが実感できますね。

最初のレビューは、作ったWordPressテーマが、Theme CheckTheme Handbook のガイドラインに準拠しているかを主に診てくれます。

そして、修正をしながら進めていくとさらにソースコートを隅々まで詳細にレビュー (complete review) してくれます。

指摘されて改善したところ (パート1)

  • ディレクトリ構成が少し特殊な形なので、構成やファイル名を見直した。
  • JavaScript ファイルは minified しか入れていなかったので、レビューできるように生のソースも追加で入れた。最初 webpack でバンドルしていたけど、出力される生のソースも特殊な出力なのでレビューできるかどうか分からなかった。ということで普通の結合 (concat) に変えた。
  • オプションのデータの持たせ方を変えた。取り回しが効きやすいようにいつも複数の options に分けて入れているけど、公式テーマだと theme_mod (一つの配列) に入れるようにすることが大切。参考: Customizer Objects#Settings
  • タブキーでのフォーカス移動などキーボード操作できるようアクセスビリティをしっかり診てくれた。特にドロップダウンメニューが展開するグローバルメニューの部分。普段キーボード操作をあまり意識していなかったのでこういうところも大切だなぁと改めて気づいた。
  • テンプレート階層を少し触っているのでそのことを聞かれた。理由を説明するとすんなり受け入れてくれた。そんなに厳格さはなく、柔軟に対応してくれるようだ。

やり取りと修正を2回ほど繰り返し、ひとまず承認された。

次にダブルチェック的な最終テーマレビューへ進む。
少しベテランな感じ?のレビューワーさんが付いてくれました。
更に細かい部分まで診てくれる。特にセキュリティ面でエスケープやサニタイジングのところ。

指摘されて改善したところ (パート2)

  • エスケープやサニタイジングを結構見落としているところがあった。のでチェックしてくれるの助かる。
  • コピーライトやクレジットの表記の見直し
  • readme.txt ドキュメントの見直し
  • ライセンス上使っていい CDN や画像などサードパーティリソースの見直し。スクリーンショットを変えた。
  • 標準コアにあるカスタマイザの機能を一部削除していたのでその調整をした。
  • javascript のグローバル変数の扱い。プリフィックスをつけるか、または即時関数にしてローカルオブジェクトにする。
  • デザイン的にボタンやメニューを画面に fixed すると。ログイン状態でページを見る場合、adminバー (ツールバー) に重なるところがある。位置をずらして重なりを回避するの厄介だった。バーの高さは通常PCで32pxでタブレットやスマホビューで46pxに変わる。adminバーはスクロールしても上部に固定されているが、スマホビューでは挙動が変わり、固定がなくなる。その高さと挙動に合わせて fixed している position を CSSやjavascriptで調整。

やり取りを繰り返し、2020年4月26日にレビューが終了した。
即日 wordpress.org にあるテーマページが公開されて、7,472点あるディレクトリ掲載テーマ (2020年4月28日現在) の一員に加わりました。
晴れて Theme Developer になりましたとさ。

WordPressテーマを公式ディレクトリ登録してみてよかったこと、感じたこと

  • WordPressエコシステムの土台に乗って世界中で幅広い人に使われるように、レビュー済みで一定の品質基準を確保した WordPressテーマができた。
  • いままでテーマの公式ディレクトリにはあまり縁がなかったけど。独自機能を実装したテーマと公式ディレクトリに掲載される準拠さをもったテーマとの技術的な比較基準をもつことができた。
  • 公式ディレクトリに登録されているテーマの完成度が上がっている。これからも上がっていく感。よく言及されるスクリーンショット映え感ではなく技術実装面で。以前はブログ用途とかスキン的な感じのテーマが多かったりソースコードを見るとグチャグチャな感じも見受けられたけど。ブロックエディタとの兼ね合いなのか技術的にそれなりのレベル、また幅広くトータルなレベルが求められている感じがする。今後テーマを一人で作り切るのはスキル的に求められるものが多くなりそうで大変そう。チームでテーマを開発するとかに進むのかなぁ。
  • 機能面の充実より、用途の提案とか、コンセプト面の充実がテーマに求められそう。そのほうが活用の広がりが生まれる。
  • 今回テーマを作ったり、WordPressテーマスタータキット「WP Theme Boilerplate」を開発したりしてきて。WordPressテーマの開発は、スクラッチから作ったり、フレームワークから作ったり。公式テーマや無料有料テーマのありあわせものでサクッと立ち上げたり、カスタマイズしたり。多様なアプローチが取れるようになってきていると思う。その都度ふさわしいやり方を選んでプロジェクトが進められそう。プロジェクトマネジメント面の発展とかにつながる。

可能性が広がっているなぁと感じる今日このごろです。

ブロックエディタにフル対応したWordPressテーマを作ってみた所感

ブロックエディタにフル対応したビジネス向けウェブサイト用のWordPressテーマ「Foresight」をつくりました

もともと去年2018年11月頃から、WordPressのブロックエディタ (Gutenberg) に対応した WordPressテーマ開発に取り組み始めましたが。いつの間にか方針転換をして WordPressスターターテーマ「WP Theme Boilerplate」を開発していました。テーマ開発は先延ばしになってしまいました。

今回ようやくWordPressテーマ「Foresight (フォーサイト)」がお披露目できてホッとしているところです。

タイミンク的に、ブロックエディタが WordPressに実装されてほぼ1年が経った頃で、その間ブロックエディタにも色々使いやすく改良が加えられて充実しつつあり、良かったんじゃないかと思います。

WordPressテーマ「Foresight」の特徴

WordPressテーマ「Foresight (フォーサイト)」の特徴は、

  • ビジネス向けウェブサイトまたはランディングページなど1ページもののウェブページが作れるように
  • 新しいエディタであるブロックエディタをフルに活用できるように

設計したテーマです。

ビジネス向けはもちろん、ランディングページはじめ、ブランディングやマーケティングで活用することを考慮して、デフォルトレイアウトに幅広なレイアウトを採用して作ってみました。ブログ・メディア向けテーマにするとサイドバーが必須になることが大半でブロックエディタの全幅・幅広なレイアウトが活かせないところもあったり。といっても必要な方にはオプション設定やテンプレートの選択でできるように作っています。

WordPressテーマ「Foresight」の公式ディレクトリへの登録は、これから登録申請する予定です。ので管理画面経由からのインストールはまだできません。しばしお待ちを。早々に試したい方は GitHub からダウンロードできますので、是非試してみてください。

ブロックエディタにフル対応したWordPressテーマを作ってみた所感

テーマのコンセプト的なことは、とりあえずテーマのプロダクトページを用意しましたので、そちらに譲ります。またテーマの技術的なことは、GitHub のレポジトリをご覧ください。この記事では、ブロックエディタにフル対応したWordPressテーマを作ってみたときに感じたことを綴ってみたいと思います。

なぜ作ったの?

4つあります。

まずは、テーマを作るのに先立って WordPressテーマスターターキット「WP Theme Boilerplate」を作ったので、これをベースに公式ディレクトリに登録されるテーマとして実績を作ることを目指しました。

2つ目がブロックエディタにフル対応したテーマを設計するというテーマ開発の動機ができた。

WordPressの関わりは、テーマ開発がはじまりで (オープンソースで公開しているのはプラグインだけで。いくつかリリースして使われているのでプラグインの人かと思われている感がありそうですが)。当時テーマを作って公式ディレクトリに登録しようと思ったが、気合を入れすぎて機能を作ったけど、プラグインテリトリなど全く知らないこともあり、登録を断念したまま時が過ぎていきました。一時テーマ販売もしたこともありますが、どちらかというとマーケティングやメディア運営が軸に活動しているところもあり、テーマ開発は、作ったテーマの改良を続けているだけでした。新たにテーマを開発する動機がありませんでしたが。

去年末に WordPress 5.0 からブロックエディタが導入されました。開発したテーマは前エディタであるクラシックエディタに対応したものがほとんどで。今回ブロックエディタに対応したWordPressテーマを作ろうという動機が少しずつ出てきたので、手を動かし始めました。ベースにある感覚は、Gutenbergを開発段階から触っていて、完成度が高まるとコンテンツ作りに集中できるなぁという感覚でした。

ツイッターでもちょこっと所感をツイートしていた。

3つ目がブロックエディタへ移行してなにかか生まれる契機になりそう、特にビジネス面で。

ウェブサイト運営の現場も変わりつつありそうなのも動機の一つになりました。

公式ディレクトリを見てみると、ブロックエディタに対応したテーマがまだまだ少ないのが現状です。今はまだブロックエディタへの移行期の途中ですね。無料有料のWordPressテーマもクラシックエディタの部分を引きずっているところがあります。(現実的には継続してアップデートを繰り返してもブロックエディタへの移行も難しいですから。特に機能部分の移行や破棄はやりづらいですね。テーマ開発者にとって辛いことですが。コツコツ頑張りましょう。ボクも以前作ったテーマで苦労している最中です〜。)

実際のウェブサイト運営の現場でも今までの業務の仕方で特に支障がないためブロックエディタに変える必要性があまり見いだせないところでしょう。クラシックエディタから使い込んでいるWordPressサイトでは、ブロックエディタへの移行もなかなか進んでいかないのも現状かと思います。

テーマの設計面やウェブサイト運営の現場など広く見渡しても一筋縄でいかず、解決策を探るべく模索がまだまだ続いていくかと思います。

その中で、特にビジネス面でなにかか生まれてくることに期待しています。その期待を見据えつつ、ビジネス向けWordPressテーマとして作ってみたところがあります。

4つ目がウェブサイト設計の知見を一層深めること。

ブロックエディタになったWordPressで、いままでのウェブページの作り方がガラリと変わります。

以前のクラシックエディタは、HTMLベースのテキスト入力 (テキストモード) あるいは見出しや太字などテキストの装飾をメインにしたビジュアル編集 (ビジュアルモード) でした。

これがブロックエディタになると、見出しや太字などテキストの装飾はもちろん、コンテンツ部分の構成やレイアウトもブロックを積み重ねるようにして作ることができます。HTMLやスタイルシートを扱わなければできなかったことが、HTMLを直接扱うことなく (ブロックエディタがその部分をうまく吸収してほとんど表に出ることなく、求められる技術スキルのハードルが下がり)、文章の作成や編集修正、レイアウト作りが誰でもできる形でウェブページが作れる。つまり、コンテンツ作りに集中できる環境がブロックエディタで実現しています。

ウェブサイトを運営する方にとっては、ホームページの開設や日々の運営していくコンテンツ作成の敷居が下がる分、ビジネスチャンスを掴みやすい環境になります。コンテンツの部分でもビジネスに発展していく機会が増えていってほしいですね。

これからのWordPressテーマ設計を考えてみる

反面、テーマ開発者はじめ、ホームページ制作やウェブサイト構築に携わっている方にとってウェブサイト構築やウェブデザインのあり方まで変わる可能性を秘めているところです。面白いところでもありますが、設計と実装面で相当の技術レベルが要求されつつあります。ウェブサイトを運営する方にとってハードルが下がるということは、設計実装面ではハードルが上がることを意味します。そこについていくことがなかなかつらい現状ですが...。

WordPressのテーマ設計面を診てみると、
ブロックエディタの導入による大きな変更は、テーマの機能として実装していた部分

  • ウェブサイト機能 (ウェブサイト全体設計の部分)
  • コンテンツ機能 (本来はプラグインテリトリに該当するかなぁ)

として機能を作り込んできたかと思います。

レイアウト機能やコンテンツを構成するコンポーネント、ウィジェット、ショートコード、ビジュアルエディタの機能拡張などを独自の設定画面を作ったり、カスタマイザに設定パネルを用意してWordPress管理画面に使いやすく実装してきました。

これからは4つのレイヤーで設計を考える

いままでWordPressのテーマ設計を考える場合、3つのレイヤーで考えるところが (テリトリにもつながるところですね)

  1. WordPress本体の機能 (標準機能)
  2. WordPressテーマの機能 (ウェブサイト機能とコンテンツ機能)
  3. WordPressプラグインの機能 (付加機能)

そこにブロックエディタが加わり、テーマの機能にあったコンテンツ機能に当たる部分がブロックエディタに移ることになると思います。以下のように。(コンテンツテリトリみたいになっていくのかなぁ)

  1. WordPress本体の機能 (標準機能)
  2. WordPressテーマの機能 (ウェブサイト機能)
  3. WordPressプラグインの機能 (付加機能)
  4. ブロックエディタの機能 (コンテンツ機能)

つまり、テーマあるいはプラグインのどちらに実装すればいいのか今まで曖昧で、はっきりしなかったコンテンツ機能の実装が、ブロックエディタの導入で明確になったことが大きいなぁと感じます。

ということで、いままでカスタマイザにあったコンテンツ機能がブロックエディタに移っていくように設計されることになるかと思います。 プラグインもコンテンツ機能を担っていたものの一部はブロックエディタ (またはカスタムブロックとして) に移りそう。特にウィジェット系はブロックエディタに統合される将来があるのかなぁとも思いますね。全体的にもブロックエディタ上に統合する形の方向にもなりそう。

またWordPressテーマ不要論もチラホラ見受けられます。が、WordPressテーマはウェブサイト全体設計として残ります。そのテーマで出来上がるウェブサイトを規定する上位の設計思想 (コンセプトの部分にあたるところ) として。WordPressテーマ「Foresight」もそんな感じで作ってみました。

WordPressは、全体を見るとなにか複雑になっているように見えますが。
設計面をこうして見ると、うまく分かれてWordPressが進化しているのが理解できますね。

ということを考えることが楽しい今日この頃です。

次世代 WordPress テーマスターターキット「WP Theme Boilerplate」をリリースしました

WordPressスターターテーマ「WP Theme Boilerplate」を開発しました。

去年2018年11月頃。WordPress 5.0 から新しいブロックエディタ (Gutenberg) が出ることだし、それにフィットする WordPressテーマを作りたいなぁと。公式に掲載してみたいなぁと。
もともと定番スターターテーマである「_s (Underscores)」をベースにテーマを作っていましたが。
気づいたらいつのまにか方針転換をしちゃって、テーマ作りより独自のオリジナルテーマがスムーズに作れる環境を作ったほうが広がりがあって面白いなぁと思い、取り組んでみました。

WordPressテーマスターターキット「WP Theme Boilerplate」 8 つの特徴

特徴は 8 つほど。

  • テンプレート階層とディレクトリレイアウトを改善
  • WordPress Theme Autoloader を実装
  • テーマの機能をクラスベースで実装
  • Theme hooks を実装
  • Block Editorに最適化した WordPressテーマを目指して Block Editor (Gutenberg) をサポート
  • Theme Starter script で独自テーマのスターターテーマを生成
  • npm scripts でテーマ開発環境を整備
  • composer scripts でテーマテスト環境を整備

スターターキットとしてテーマ開発環境を整備

  • フロントエンド開発環境
  • WordPressテーマ開発環境
  • テスト環境 (ユニットテストや静的コード解析、CI/CDまで)

この辺がサクッと整備されたらいいなぁと。

ただ効率的にテーマがつくれることだけを追求してもだめで。(単にテーマを作れるだけでは価値はだんだんなくなってくる)
一番価値が生まれるところである、デザインやコンテンツにきちっと時間を割きたい。
ビジネスにスピードと柔軟性が求められている中でプロトタイプ的な、アジャイル的なアプローチで開発ができるようにしたい。
常に改善されるテーマになるよう機動性を手に入れたい。
新しい価値を生み出す今の開発環境にマッチできるような設計思想をいくつか組み入れてみました。

結果、ただテンプレートが揃っただけのスターターテーマではなく、開発環境やテスト環境など周辺環境を整えた「スターターキット」にしてみました。

テーマ設計で感じたこと

WordPressテーマは、ディレクトリ直下にテンプレートファイルが置かれる (WordPress 全体から見るとテーマフォルダ自体が View って感じな、テーマ開発者にとって View がディレクトリ直下にある感じな) ので、
ディレクトリ構成上フラットになりやすく、いろんな種類や役割がファイルが混ざってくる。
シンプルなテーマなら気にならないが、開発しているとファイルが散らばり複雑になってくる。
のちのち開発効率や開発意欲の低下がボディブローのように効いてくるので手を入れて整理してみた。

シンプルにテンプレートファイルを一つ下のディレクトリにまとめるアプローチで解決する。
テンプレート階層にも関わってくるので、複雑なことはしないようにする。
WordPressは、テンプレートの選ばれ方を把握していないとそう簡単に動かすことはできないけど。
これでディレクトリレイアウトが少しばかり整理される。

次にテーマの機能を関数からクラスベースに変える。
従来だと、関数名がWordPressコアの関数や他のテーマ・プラグインの関数とかぶらないように
関数名を「テーマ名のプリフィックス_関数名」みたいに先頭に namespace をつける。ので関数が必然的に長くなる。
また開発を続けていると、どの機能に関係している関数か、この関数はどこに影響や副作用を及ぼすのか、
functions.php が肥大したり、次第にまとまりがわからなくなってくる。
方向性としてテーマの機能は、クラスベース (クラスファイル) で namespace をつかってそれぞれの機能が分離するように再設計した。

そのクラスファイルは、composer autoloader のように自動的に読み込んでくれるように
WordPressのファイル命名規則に基づいて WordPress Theme Autoloader を実装してみた。
必要ならば composer autoloader を使って外部のライブラリにある機能を取り込めることもできるし。
大掛かりにならない程度の実装で機能を取り込めるように、開発が楽しくなるように目指してみた。

メインテンプレートには、複雑なロジックを入れないようにベースとなるレイアウトだけ定義する形がよさそう。
そしてパーツとして切り分けたファイルをメインテンプレートに読み込むのが基本線。
また wp_head, wp_footer などテンプレートタグにフックする。(最近 v5.2 だと wp_body_open が出てさらに便利になったね)

フックは WordPressの大きな特徴で醍醐味な部分なので。(フックを覚えたらWordPressの開発が楽しくなると思うなぁ)
テーマ専用のフックがあってもいいのではなかろうか。(将来共通化したものが出てくれたらうれしい)
ということで Theme hooks を実装してみた。
メインテンプレートのレイアウトの所々にいくつか設けた Theme hooks に引っ掛けることでメインテンプレートには手を入れずに追加要素を差し込んだり、フックした関数 (アクション) 側で複雑なロジックを組み入れることを目指してみたい。

あなただけのオリジナルWordPressテーマをつくろう

独自テーマが作れるように Theme Starter script を用意してみました。
テーマ名を引数に Theme Starter script を走らせるだけでオリジナルテーマの雛形がすぐに生成されます。
そこからあなただけのオリジナルWordPressテーマをつくっていける開発環境ができあがる。
WordPressテーマを作れる環境はすでに目の前にあります。
WordPressテーマ作りを楽しく過ごしてみてね。

素敵な、便利な、魅力的な WordPressテーマがたくさん生まれたり、
面白い、読み応えのあるコンテンツがある WordPressサイトがいっぱい出来上がったり、
テーマ開発やWordPress構築プロジェクトを成功に導いたりと。
WP Theme Boilerplate が縁の下の力持ちとして
少しでも力になれば幸いです。

リソース

今後すること・したいこと

今後やることをメモ。

  • テストを書く
  • ドキュメントをつくる
  • WP Theme Boilerplate をベースに公式テーマを (やっと) つくる

BashテストフレームワークBatsのヘルパースクリプト「Bats Assertion」をつくりました

Bash のシェルスクリプトは、エンジニアが片手間に書いて使う DIY 的な使い捨てスクリプトになりがちぎみだけれども。
Bash のシェルスクリプトを作ってオープンソースとして公開している手前、
「きちっとテストを入れたいなぁ」と思っていろいろ Bash のテストどうやるの? というところから始まって
どんなアプローチがあるのだろうといろいろ調べたり試したり。
結果、Bashテストフレームワークとして「Bats」がシンプルすぎるぐらいに良かったので採用してみました。

Bashテストフレームワーク「Bats」とは

Bats の正式名称は、Bash Automated Testing System。

ドキュメントには、

Bats is a TAP-compliant testing framework for Bash.
(訳: BatsはBash用のTAP準拠のテストフレームワークです。)

とある。

使い方は、.bats 拡張子を付けたファイルにテストケースを書いていくだけ。
例えば、example.bats に以下を書いて

#!/usr/bin/env bats

@test "status - return 0 exit code" {
  run bash -c 'exit 0'
  [ "$status" -eq 0 ]
}

@test "output" {
  run bash -c 'echo -e "abc"'
  [ "$output" = "abc" ]
}

@test "lines" {
  run bash -c 'echo -e "abc\ndef\nghi"'
  [ "${lines[0]}" = "abc" ]
  [ "${lines[1]}" = "def" ]
  [ "${lines[2]}" = "ghi" ]
}

テストを走らせると、

bats --tap example.bats

テスト結果が得られます。

1..3
ok 1 status - return 0 exit code
ok 2 output
ok 3 lines

テストケースのプロセスは、
run でコマンドを実行し、
その結果が 3つの変数に保存されます。

  • $status - exit status を保存
  • $output - 標準出力またはエラー出力を保存
  • $lines - 標準出力またはエラー出力を行単位で配列で保存

それら変数を確かめたり、アサーションしたりする。

setup, teardown もあるので、
いろんな設定を想定したテストケースが作れると思います。

Bash だけでなくいろんな言語のコマンドラインツールで使えて
シンプルなテストには、もってこいのテストフレームワークです。

ヘルパースクリプト「Bats Assertion」

今回、その Bats のヘルパースクリプト「Bats Assertion」をつくりました。

Assertion 系のヘルパースクリプトは、ほかにもありましたが、
テストを書くこと自体がテストドキュメントになる。
もっとシンプルに書けて、テストを書くことが億劫にならず、
テストを育てていく感じにならないかなぁと思って設計してみました。

使い方は、ヘルパースクリプト「Bats Assertion」をダウンロードして
テストファイル内で Bats の load コマンドで読み込むだけ。

load bats-assertion/bats-assertion

読み込むと、以下の assertion 系のコマンドが使えるようになります。

  • assert_success
  • assert_failure
  • assert_status
  • assert_equal
  • assert_fail_equal
  • assert_match
  • assert_fail_match
  • assert_lines_equal
  • assert_fail_lines_equal
  • assert_lines_match
  • assert_fail_lines_match

それぞれのコマンドの詳細は Assertion Reference を参照してみてください。

ヘルパースクリプト「Bats Assertion」で書き換えると

先の example.bats をヘルパースクリプト「Bats Assertion」で書き換えると、
こんな感じになります。

#!/usr/bin/env bats

load bats-assertion/bats-assertion

@test "status - return 0 exit code" {
  run bash -c 'exit 0'
  assert_success
}

@test "output" {
  run bash -c 'echo -e "abc"'
  assert_equal "abc"
}

@test "lines" {
  run bash -c 'echo -e "abc\ndef\nghi"'
  assert_lines_equal "abc" 0
  assert_lines_equal "def" 1
  assert_lines_equal "ghi" 2
}

assertion 系のコマンドを体系化することでテストが書きやすく、
一目見ただけで分かりやすいテストケースになって
そのままテストドキュメントにもなればなぁと思います。

ドキュメント

リソース

最近の投稿

カテゴリー

アーカイブ