Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
前置き 地味にこの記事が読まれ続けているみたいなのですが、内容がよい加減に古くて心苦しいので、もうちょっと現代的な内容にマイグレーションしたものを投稿しようと思います。当時と違ってQiitaにもよい記事増えているのに今更感あるのですが、あの記事に辿りついてしまった人のため……という感じで書いておきます。 大前提 PHPUnitを使ったからといって、どんなソースコードもテストできる訳ではありません。テストをし易いようにクラスを設計している必要があります。また、そのように設計していてもUnitテストに入れることの出来ない箇所は出てきます。Unitテストに入れることの出来ない箇所は出来ないと割り切らなければなりません。むしろ、どれだけのコードをUnitテストに入れることが出来るか? というのが設計者の腕の見せどころになるでしょう。極論を言うと 「どんなクラスでも疎結合に実装していなければならない
FuelPHP Advent Calendar 2015 の18日目を担当します @hmukaida です。よろしくお願い致します。 今回は、FuelPHP で開発している WebAPI を VAddy というクラウド型Web脆弱性検査ツールを使ってテストする話をしたいと思います。FuelPHP 部分は弱めかと思いますが、18日目が空いていたので参加させていただきました。 はじめに フレームワークを使った開発では、ユニットテストやE2Eテストを行うのはもはや日常になってきているかと思います。当然私達の現場でも実施しています。 特にセキュリティ対策としては、各種サーバでの対策もそうですが、フレームワーク独自の対策を施したり、IPAの安全なウェブサイトの作り方を読み込み実践したりと様々取り組んできました。 しかし、数あるAPIの様々なリクエストにどれくらいの脆弱性が潜んでいるのか不安でなりませ
ネットの検索結果でチラチラとは見ていたのですが、この度初めて自分でもDBUnitを使ってみました。ネット上のサンプルコードをほとんどそのまま実行しただけですが、私の手元でも簡単にユニットテスト用のDBとデータを準備することができました。 従来、H2 DatabaseはRunScriptで初期化用のスキーマを流し込んでいたのですが、これならJDBCドライバを選ばない気がします。 ※ 他のJDBCドライバでH2 DatabaseのINIT=RunScript相当の機能が可能なのか知りません。 ##環境 DBUnit 2.5.1 JUnit 4.12 ユニットテストのコード(パクリですが) 以下のような感じです。Excelファイルもデータソースとして使える点は、仕事でプログラムを作る人にとってかなりのアドバンテージな気がします。 import java.io.File; import org.j
FuelPHP Advent Calendar 2015の6日目を担当する@wataです。昨日は@sharkppさんのNestedSets Model を使って FuelPHP 用コメントボックスパッケージを作った話でした。 本記事ではFuelPHPを用いた開発におけるユニットテスト、特にデータベースまわりに関するテストケースの作成について、保守性の面から色々考えたあれこれを書かせていただければと思います。 FuelPHPのテスト事情 突然ですがみなさん、テスト書いてますか? PHPはとっても柔軟(?)な言語なので、品質を担保するためにはいつでも実行可能で、軽量なテストによって、動作が常に正しいことを検証できることが望ましいとされています。 PHPの場合、テスティングフレームワークとしてはPHPUnitが有名であり、多くのテスト支援のための機能が実装されています。FuelPHPも例外なくP
「はじめに」の「はじめに」 2016年版としてマイグレーションしました。 特にこだわりが無い場合は、こちらを参照してください。 はじめに こんな感じで資料を作ろうとしていた草稿です。 文中のソースコードの正誤とかは見きれていません。 ツッコミとか有れば、よろしくお願いしますm( _ _ )m PHPUnitを使ったからといって、どんなソースコードもテストできる訳ではありません。 テストをし易いようにクラスを設計している必要があります。また、そのように設計していてもUnitテストに入れることの出来ない箇所は出てきます。Unitテストに入れることの出来ない箇所は出来ないと割り切らなければなりません。むしろ、どれだけのコードをUnitテストに入れることが出来るか? というのが設計者の腕の見せどころになるでしょう。 極論を言うと 「どんなクラスでも疎結合に実装していなければならない」 ということで
単体テストはpublicで公開されているものだけで十分という意見が主流のようだ。 しかしprtectedメソッドにもサブクラスに「使ってもらう」意図がある場合など、むしろしっかりテストで固めておきたい場合もある。 prtectedで定義されたメソッドは外部から呼べないので、テストは難しい。 よくやる方法は、単体テスト用にターゲットクラスのサブクラスを作ることだ。 PHPではメソッドのオーバーライドするときに、アクセスレベルをprotectedからpublic に緩めることができるので、 そのなかで親クラスのprtectedメソッドをしれっと呼び直せばよい。 <?php class Target { protected function getRealName() { return __METHOD__; } } ?> <?php class TargetExp extends Target
<?php require_once 'SampleClass.php'; class SampleClassTest extends PHPUnit_Framework_TestCase { public function testAccessProtectedProperty() { $foo = self::getProperty('foo'); $obj = new SampleClass(); $this->assertTrue($foo->getValue($obj)); } public function testAccessProtectedMethod() { $foo = self::getMethod('hoge'); $obj = new SampleClass(); $this->assertTrue($foo->invokeArgs($obj, array())
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く