こんにちは、pixivでPHPをやってる@tadsanです。好きなテスティングフレームワークはPHPUnitです! 好きな某CALOIDはテトさんです! みなさまはユニットテストを書いていらっしゃいますか? 今回はDocCommentとPHPUnitのデータプロバイダーをうまく利用してテストの記述を省力化する手法を紹介いたします ヾ(〃><)ノ゙ 提案手法 実装のDocCommentに「期待値」と「入力パラメータ」を記述することで、テストケースメソッドをいちいち追加せずともユニットテストできるようになります。また、入力(パラメータ)と出力(期待値)を明記することで、実行せずともコメントとしてわかりやすくする効果があります。 <?php /** * @route\example http://touch.pixiv.net/member_illust.php?mode=medium&illu
※6.3のドキュメントから引っ張ってきてます 規則 ・クラス名は「対象名Test」 ・テストを行うメソッド名は「test*」 ・「PHPUnit\Framework\TestCase」を継承する ・テストはコードを上から下へなめていく 書き方 例 <?php use PHPUnit\Framework\TestCase; class HogeTest extends TestCase { public function testHoge() { $stack = []; $this->assertEquals(0, count($stack)); } } アサーション テストの結果を判定するメソッド。 「$this->アサーションメソッド」「self::アサーションメソッド」のいずれかの方法で使用する。 引数にメッセージを指定すると、エラー時に出力してくれる。 下記で主に使うものを抜粋。
概要 Laravel で Controller のクラスをテストしたいと思ったのですが、Controller にドメインロジックが入り込んでいてテストしずらかったので、どうすれば Controller のテストがしやすくなるか考えながら、サンプルプロジェクトをつくってみました。 余談ですが、現在、Laravel4 のプロダクトと Laravel5 のプロダクトを同時に改修していて、あちこち混乱したので、両方のバージョンで同じことをやってみました。 やったこと Controller からドメインロジックを追い出すために、サービスクラスをつくって処理を移した Controller のテストでは Mockery を使ってサービスをモック化した 環境 PHP 5.6.9 Laravel 4.2, 5.2 4 と 5 の主な違い 5 では Mockery がデフォルトでインストールされる 5 では
I've just started using PHPUnit and am wondering if there is a build in way of dumping the contents of a variable? The use-case being that since I am already talking to the code I'm developing, I can use PHPUnit not only to test the stability of that code but also to output debug info while being in development. I know xdebug can fill this gap for me, but sometimes it's just easier to dump some in
最近になってPHPUnitをちゃんと使ってユニットテストを書くようになってきたのですが、まだまだTipsが足りないと感じます。個人的に実践している書き方をいくつか並べてみます。 追記:最初、シェバングと書いていましたが、オプションを渡せる数が決まっていたりOSによっては動かなかったりとあまり便利でないことがわかりました。。phpunit.xmlを書いた方がいいかも。 ちょっとしたテスト → シェルスクリプト化する PHPUnitは高機能なのですが、いかんせん最初の障壁が高いと思います。とにかく気軽に書きたいなら、シェルスクリプトを作って単独ファイルで実行できるようにするといいです。 #!/bin/sh phpunit --colors *Test.php # ↑オプションを書き並べておく <?php class SampleTest extends PHPUnit_Framework_Te
LaravelではPHPUnitが組み込みで入っていますが、テストコードのカバレッジを可視化する機能は別で設定する必要があります。 カバレッジ(網羅率)とは、テストコードがアプリケーションのロジックをどの程度カバーできているかの割合のことです。 RPGゲームのダンジョンの踏破率とかがイメージとしては近いかもです。 テストコードを整備・管理するにあたってカバレッジ測定ができれば、 「テストコードの量は多いけど、同じロジックのテストばかりで意外とカバレッジ低かった」 「この機能のテストコードを整備してカバレッジを上げよう」 「ここは既に十分なカバレッジがあるから、そこまで注力しなくていいか」 みたいなことができます。 PHPUnitもXdebugを導入することでカバレッジ測定をできるようになるので、手順を解説していきます! ざっくり手順 ①X-Debugの導入 ②ライブラリ(php-code-
PHPプロジェクトのテスト PHPのテストによく使われているのはPHPUnitとPHPSpecです。基本的にPHPUnitはすべてのテストをカバーできますが、自分はPHPSpecを優先にして、PHPUnitがバックアップっていう感じで使ってます。PHPSpecはオブジェクトの挙動を検証するには得意だが、サイトのリスポンスなどのテストはちょっと苦手です。 Laravel5のテスト LaravelではすでにUnitテスト実装済みです。PHPUnitについては公式サイトを参考してください: http://laravel.com/docs/5.0/testing PHPSpecを使う LaravelのEloquentモデルはちょっと特殊で、PHPSpecを使うには面倒なセッティングが必要なので、phpspec-laravelを使うのをおすすめします: https://github.com/BenC
開発者ならお気に入りのツールやワークフローがあると思いますが、他の開発者のツールややり方も気になりますよね? そこで、11人の著名なPHP開発者に、よく使うツールやワークフローを伺いました。 開発者はプロジェクトの最終成果物を完成させるために自分なりのプロセスを編み出しています。そのプロセスには、試行錯誤の末にたどり着いたツールが含まれます。「プロセス」と「使うツール」が決まると、ワークフローが完成します。ワークフローは、開発者が直面するプロジェクト管理上の問題を減らせるので、開発者は自分のワークフローにこだわります。 ワークフローの構築は経験と試行錯誤(苦悩の時間です)が必要なので、エキスパートは新米開発者に、優れた開発者のワークフローを学び、真似することを薦めます。新米開発者も時間をかけて使えるものを取り入れつつ使えなかったものを捨て、プロジェクト開発に使う自分のツール集を編み出すので
DBを使ったテストを考えた場合、 ・Insertのテストが走るとTableにそのデータがInsertされテストが正常完了する ・上記テストをもう一度走らせると、前回のInsertされたデータがあるのでDuplicateでテストが失敗する 上記の問題を解決することを考える ・テストが走るとテーブルが初期化される ・Insertのテストが走ると初期化されているので、前のテストでInsertされたデータは消えているので、Duplicateにはならない。 phpunit/dbunit ・テストが接続するDB情報を設定できる ・テストが走るとテーブルのデータが初期化される インストール Composerを使ってインストール
アライドアーキテクツの伊藤です。 前回のエントリでは、PHPUnit系のお話を書きましたが、今回もしつこくPHPUnit系のお話を書きます。PHPUnitでテストを書いている時、データベースへの接続が発生するようなテストがあった場合、皆さんはどうしてますでしょうか。 レガシーコード改善ガイドによれば、データベース接続を伴う単体テストはあまり望ましくない為、データベース接続を伴うクラス、メソッドとの依存関係を排除して単体テストを書くべきとあります。 僕もそれが本来あるべき姿だと思いますが、今回はその話は一旦横に置いておき、PHPUnit上で使えるDBUnit拡張について書かせて頂きます。 使い方 通常のテストクラスは「PHPUnit_Framework_TestCase」を継承して作りますが、DBUnitを使う場合は「PHPUnit_Extensions_Database_TestCase」
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。 2014/10/23現在、ComposerでLaravelをインストールするとPHPUnitは入っていません。 既に環境にPHPUnitがインストールされていればよいのですが、そうでない場合は一手間かかります。 まずはcomposer.jsonを編集します。 "require-dev": { "phpunit/phpunit": "4.3.*", "phpunit/dbunit": ">=1.2", "mockery/mockery": "dev-master@dev" }, こちらを追加しましょう。mockeryはモックのライブラリです。 $ composer update これで上記のライブラリがインストールされます。 その後、vendor/binをPATHに追加することでP
namespace App\Tests; use Artisan; use DB; use Mockery as m; class TestCase extends \Illuminate\Foundation\Testing\TestCase { /** * データベースの利用フラグ */ protected $useDatabase = true; /** * Creates the application. * * @return Symfony\Component\HttpKernel\HttpKernelInterface */ public function createApplication() { $unitTesting = true; $testEnvironment = 'testing'; return require __DIR__.'/../../bootstr
動機 PHPのテストフレームワークといえば(たぶん)PHPUnitが一番に挙げられると思いますが、歴史が長いだけにテストの書き方も古風というか今風ではないというモヤモヤを感じる今日この頃。 他のテストフレームワークで台頭しているのはPHPSpecとかBehatあたりだと思いますが、普段jsでmochaとchai(最近はpower-assert)を使っている身からするとどちらもしっくりきませんでした。 そんなわけでjsのモダンなテストフレームワークに近い書き方ができるPHPテストフレームワークを探してみたところ、Peridotというものを見つけたのですが、これが思いの外使い勝手が良かったので、紹介と共に普及活動としてスターターキットやGulpプラグインを作ってみました。紹介はのちほど。 ちなみにPHP5.4~対応なのでレガシーなシステムでは導入できません。ご注意を。 Peridotの紹介 ま
The document defines a fib function that recursively calculates Fibonacci numbers and prints the 10th Fibonacci number. It then defines some unit tests for a Calculator class that test the add method by asserting the expected result. Finally, it defines some unit tests for a User class that test validating a user object.Read less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く