PHPUnitのデータプロバイダーを試す - Qiita
<?php namespace Sample; class Sample { // $a + $b を返す public function Add($a, $b) { return $a + $b; } // $a - $b を返す（実際は間違っている） public function Sub($a, $b) { return $a + $b; } } <?php use PHPUnit\Framework\TestCase; use Sample\Sample; class SampleTest extends PHPUnit\Framework\TestCase { public function test_add() { $sample = new Sample(); $this->assertEquals(10, $sample->Add(4, 6)); } /** * @data
PHPでリフレクションはこうでしょうが！ - Qiita
テストを書くときにprotected,privateなプロパティを書き換えたいときがあります。 でも、なかなかそらで書けないのです。僕は。 だから、自分への戒めとして書いておきます。 （そもそもアクセスできないテストってどうなの、、、ってのはありますが、、、） リフレクションはこう！こう書く！！覚えろ！自分！！ $reflection = new \ReflectionClass($Mailer); $property = $reflection->getProperty('oauth'); $property->setAccessible(true); $property->setValue($Mailer, true); $this->assertTrue($Mailer->getOAuth()); Register as a new user and use Qiita more c
Laravel5.6でPHPUnitのコードカバレッジを出力する - Qiita
概要 MacOS上のLaravelのプロジェクトのコードカバレッジをHTML形式で出力します。 Laravelでプロジェクトが作成されており、PHPUnitが実行可能な状態を前提としています。 Xdebugのインストールについても手順を記載しています。 手順自体は簡単ですが、Xdebugのインストールで迷うことがあったので、メモとして記事にしています。 環境 Mac OS X Sierra 10.12.6 Laravel5.6 PHPUnit7.0 手順 composer.jsonのscript カバレッジを出力するためのコマンドをcomposer.jsonのscriptに追加します。 カバレッジの結果がHTML形式でcoverageディレクトリに出力されるように修正しています。
PHPUnitの実行をさっさと終わらせたいとき - Qiita
よくあることですが、PHPUnitでテストを書いている場合、テストケースが増えてくると徐々に実行速度が気になってきます。テストの量が増え、完了するまでの時間が単純に増えていくためです。 そんなとき、とにかくテストをさっさと終わらせるためのtipsです。 テストする量を減らす ローカルで開発するときは毎回すべてのテストを実行する必要はないかと思います。そんなときはテストする量自体を減らしましょう。 filter や group オプションを使用し特定のテストだけ実行すると、実行テストの総量が減り完了までの時間は短くなります。 参考: PHPUnit で指定したのテストのみを実行する また、PhpStormなどのエディタの機能を使えば特定のテストを実行することがエディタ上で可能になります。 参考: Testing with PHPUnit カバレッジを計測しない filter や group
CakePHP3.6のコントローラでのPHPUnitの使い方メモ - Qiita
何かと理由（時間がない || メンテが面倒）をつけて避けがちなユニット試験。 未だ関わる開発現場で全くユニット試験が書かれていないことも多い。 とは言え、急な仕様変更に伴うデグレ確認や後々の保守開発を考えれば必須かなと。 PHPでユニット試験といえばPHPUnitが有名。 CakePHP3上でコントローラのユニット試験を動かす時にちょっと詰まりました。 その時のメモ書き程度に残しておきます。 動作環境 PHP7.2 CakePHP3.6.9 MySQL5.7 環境構築 composerのパスを通していること. // CakePHP3初期化(プロジェクトが無い人) composer self-update && composer create-project --prefer-dist cakephp/app xxxx // PHPUnitインストール composer require --
PHPUnitで「例外が投げられないことを期待する」というテストケースをどのように書くか - Qiita
こんな「困った」時の話 「異常時に例外を投げる、正常に完了したらvoidとなる」というようなメソッドがあるとします。 こんな時に、PHPUnitでどのように単体テストを書けばいいでしょうか？ PHPUnitでは、1つもassertionがないテストを「Risky」としてマークします。これは賢いのですが、しかし「返り値をとれないメソッド」=assertionを置けないテストケースについてRiskyになってしまうのが困る・・・と悩んでいました。 結論: @doesNotPerformAssertions を使えそう テストケースのアノテーションに @doesNotPerformAssertions を入れると、「これはリスキーじゃないぞ」という事を示すことができそうです。 以下、「こうやって対処してきた」「これからは@doesNotPerformAssertionsを使いたいかも」という話をし
CircleCI で PHPUnit を並列実行する - Qiita
CircleCI のテストの並列実行は、テストファイルをインスタンス毎に振り分けることで実現します。しかしながら、PHPUnit のコマンドライン (phpunit) は複数のファイル名を受け取って実行するということができません。 circleci tests glob "tests/**/*Test.php" | circleci tests split # => インスタンスに割り当てられたテストファイル名のリスト (スペース区切) # => そのままでは phpunit で実行できない... そこで、ファイル名のリストを引数にとって、そのテストを実行するための phpunit.xml (phpunit-partial.xml) を生成するツールを書いて対応しました。 phpunit-xml-gen.php <?php $files = array_slice($argv, 1); $
Spring Test DBUnit でテスト毎にテーブルを用意する方法 - Qiita
各バージョン 訳あってSpringのバージョンが3.2.8.RELEASEですが、4系の最新版でも問題ないです。 その場合、Spring Test DBUnitのバージョンは、1.3.0が良いです。 Java 1.8.0 update 92 Spring Framework 3.2.8.RELEASE Spring Test DBUnit 1.0.1 DbUnit 2.5.2 H2 Database 1.4.191 JUnit 4.12 背景 Spring + DbUnit + Spring Test DBUnit を使ってDB関連クラスの単体テストを行う場合に、 各開発者の環境やCI環境においてそれぞれの環境でDBを用意するのは大変なので、 インメモリなH2 Databaseを採用することは少なくないと思っています。 <bean id="dataSource" class="org.h2
DBUnit - DatabaseOperationの挙動 - Qiita
「データセット」とは？ DBUnitについて調べてて気になったのが「データセット」という単語。 DBUnitの説明に必ず出てくる割には、これがどういったものなのかぴったりくる説明がありませんでした。 これは、テーブル名・カラム名・データ・主キー の情報のかたまりです。 この情報はIDataSet#getTableMetaData()で取得できます。 ちなみに主キー情報はテーブルからデータを取得した時に設定されます。 DatabaseOperationについて試したり調べたりする機会があったのですが、現在のバージョンではJavadoc(英語)くらいしかいい資料がなかったのでまとめてみました。 もし外部キー制約違反や一意性制約違反が起こった場合は、org.dbunit.DatabaseUnitExceptionが発生します。 この例外は、各DBMSの例外をラップしています。 全てのDataba
DbUnitとH2 Databaseでデータベースのユニットテスト はじめの一歩（環境構築、初期値データのセット、XML/Excel/CSV テーブルの比較） - Qiita
DbUnitとH2 Databaseでデータベースのユニットテスト はじめの一歩（環境構築、初期値データのセット、XML/Excel/CSV テーブルの比較）JavaJUnitgradleDBUnith2 はじめに データベースを使ったJavaアプリケーションのユニットテストが難しい理由として以下の３つがあげられると思います。 1. データベースのセットアップの問題 2. テストコードやテストデータのメンテナンス性の問題 3. テストに時間がかかる問題 これらの問題に対応するため、DbUnit（リンク）とH2 Database（リンク）を使ってユニットテストをしてみます。 DbUnitは、依存しているライブラリが多いため、Gradleを使って環境構築していきます。 DBUnit DBUnitは、JUnitのデータベース用の拡張モジュールです。 xmlファイルに書いたデータベースの状態をセッ
Spring Boot で DB アクセスまわりのテスト - Qiita
Spring Boot に限った話ではないんだけど、今回 Spring Boot で書いたので、そんなタイトルに。 必要とされるシーンが多いわりに、意外と情報が少なかったので、まとめておきます。 DbSetup を使用するものと、DBUnit を使用するもの、それぞれを紹介します。 なお、今回はテストに Groovy Spock を使用します。 検証に使用したものを GitHub に公開しておいたので、こちらを確認しながら追いかけると、より理解しやすいかもしれません。 https://github.com/yo1000/com.yo1000.edu.boot.dbtest 環境 Java 1.8.0_91 Maven 3.3.9 (Maven wrapper) Spring Boot 1.4.0.RELEASE Groovy 2.4.7 Spock 1.1-groovy-2.4-rc-1
Spock ライクにテストデータを表現する - Qiita
過去にこんな記事 (Spock ちっくにテストデータを挿入してみた話) も書きましたが、最近は DBUnit だけでなく、DbSetup を使用することも多かったので、当時作成したモジュールをアップデートしてみました。 なかなかいい感じにデータ表現できるようになったので、ご報告。 環境 Java 1.8.0_91 Maven 3.3.9 Groovy 2.4.7 Spock 1.1-groovy-2.4-rc-1 DbSetup 2.1.0 DBUnit 2.5.3 $ ./mvnw --version Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-11T01:41:47+09:00) Maven home: /Users/yo1000/.m2/wrapper/dists/apache-maven
Spock ライクにテストデータを表現する その2 - Qiita
過去に以下記事にて、Spock ライクにテストデータを表現することにチャレンジしてきました。 Spock ちっくにテストデータを挿入してみた話 Spock ライクにテストデータを表現する それでもまだ、col、row といった記述が残ってしまっており、より Spock ライクな記述に近づけることはできないかと考えていたところ、他にも似たようなことを試している方がいることに気が付き、参考にさせていただきました。参考にさせていただいたのは以下記事、およびプロジェクトです。 Javaのテストでも使えるテーブルセットアップ用のGroovy DSL https://github.com/disc99/hogan そして、完成したのがこちら。 https://github.com/yo1000/dbspock テーブル名A { 列名A1 | 列名A2 | 列名A3 | ... '行A1:値A1' |
DBUnitでBLOBデータをEXCELから放り込んだ話 - Qiita
これはJava Advent Calendar 2016 ¥- Qiitaの10日目の記事です。 9日目の記事はdeaf_tadashiさんのマイクロベンチマークツール、JMHについて でした。 11日目は @leak4mk0 さんです。 このページについて DBUnitを使用して、BLOB型カラムにテストデータ（主に画像とか、PDF）を入れたいときには、 XMLでそのファイルを指定する仕組みが用意されています。 が、今回は、EXCELからBLOB型カラムにテストデータを入れる方法を紹介したいと思います。 DBUnitを使ったことがない方は、使い方については、日本語情報が沢山あるので、 ぐぐってみてください。 書く目的 BLOB型カラムのデータをインポートする際に躓いたので、その共有です。 レアリティの高いシチュエーションだとは思いますが、 こんな方法でいけるぜ！というのを知っていただけれ
Spring Boot, Spock, DBUnit でトランザクションを使ったテスト - Qiita
Spring では、テスト対象の内部だけでなく、テストそのものの前後にもトランザクションを使用できます。テストデータを作成するライブラリのひとつである、DBUnit を使用することで、テストデータの挿入についても、同じトランザクションで管理できるようになります。 テスト対象メソッドの Propagation 設定にもよりますが、多くの場合設定されているであろう Propagation.REQUIRED (@Transactional アノテーションでのデフォルト設定値) を使用していれば、テストで開始したトランザクションを、テスト対象にも引き継ぐことができ、テスト対象メソッドの内部でデータに変更が生じたとしても、テスト終了時にこの変更をロールバックすることができるようになります。 環境 Java 1.8.0_91 Maven 3.3.9 (Maven wrapper) Spring Boo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DbUnitでの予約語のエスケープ方法 - Qiita
【PHPUnit】assertEquals()は使わず、assertSame()を使おうという話 - Qiita
PHPUnitの遅いテストケースをあぶり出すphpunit-speedtrap - Qiita
PHPUnitでReflectionMethodを使うときは@coversアノテーションがトレーサビリティを上げる - Qiita
【PHPUnit】getMockForTrait()でtraitをさくっとUnitテストする - Qiita