簡単！ JavaScriptで自動UIテスト (NodeJS, Selenium Webdriver, WebdriverIO, mocha, gulp) - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
PHPUnitのコードカバレッジが遅いからってあきらめずに、並列実行ためしてみる - Qiita
はじめに PHPUnitにはコードカバレッジ解析の機能があります。 このカバレッジの出力には、かなり時間がかかります。 チームメンバーからCIのテストが遅いので何とかしてほしいと、issuesがあがってきたので、スピード改善できないか検討し、最終的には並列実行することで、大幅に改善することができましたので、紹介します。 コードカバレッジの出力 カバレッジを出力するには、phpunitコマンド実行時のオプションに--coverage-*を指定します。 phpunitのヘルプに詳しい説明があります。 $ bin/phpunit --help PHPUnit 4.8.6 by Sebastian Bergmann and contributors. Usage: phpunit [options] UnitTest [UnitTest.php] phpunit [options] <direct
MockeryとPHPUnitを使う（最低限） - Qiita
PHPUnitでMockeryを使う場合の最低限のメモ。 Mockeryとはなんぞや？ Mockを作るためのツール。要は、存在しないClassを代替してテストを進めるためのツールと思ってよい。 下記のようなコードがある場合、どうぜんHogeClassが存在することが前提となる。 が、大きなプロジェクト等で「まだHogeClassが無い！」などという場合でもある程度テストを進めておける。 //インスタンス生成 $m = new Hoge('foo'); //メソッドを実行 $m->Hello('foo'); //assertの中で使う $this->assertEquals("Hello foo",$m->Hello('foo'));
同値分割・境界値分析の解説 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 同値分割とは 同値分割は、さまざまなテストフェーズで利用できるブラックボックステスト技法の一つです。テスト結果（ソフトウェアの振る舞い）をグループ分けし、それぞれのテスト結果になる代表的なテスト条件を選択してテストします。言い換えれば、すべてのテストをするのではなく代表的なテストをすればよい、という考え方です。一般的にはテスト技法の基礎といわれています。 本来はテスト結果（数学的な表現をすると値域）に着目するテスト技法ですが、ここではテスト条件（数学的な表現をすると定義域）に着目する方法を解説します。 同値分割は大きく5つの作業に分けら
EUnitでapplicationを起動したテストを書く - Qiita
元々はNIF用に用意されているのだと思うのだが, moduleがloadされた際に実行する関数を指定することができる. これを使って, applicationの起動が必要なテストはここで起動処理を書いたりしていた. ただ, 本来の用途でないだけあって困ったことがいくつかある. テスト終了後の挙動 on_loadで起動したアプリケーションは, test終了後exit(Pid, kill)で終了される.これによる副作用がある. applicationにはloadに関するステータスとして loaded loading そして, startに関するステータスとして started running が存在するが(ちなみに, これらはapplication:info/0を呼ぶことで取得することができる), exitされるとrunningからは消えるがstartedに残るという現象が発生する. そして,
IntelliJ IDEA(PhpStorm)からDocker上のphpでphpunitを実行する - Qiita
ほとんど本家の記事の意訳に近いですが、Intellijからdocker上のphpでphpunitを動かす設定をしてみました。 本家の記事: https://blog.jetbrains.com/phpstorm/2016/11/docker-remote-interpreters/ 環境 IntelliJ IDEA 2017.1.4 PHP Docker pluginをインストール 手元で確認はしていないですが、元訳がPhpStormなので、PhpStormでも同じかと思います。 Remote Interpreterの設定 Preferences -> Languages & Frameworks -> PHPを開きます CLI Interpreterの[…] ボタンをクリックします CLI Interpretersの画面が開くので左上の[+]をクリックし[From Docker, Vag
Angular4(Angular2~)のユニットテスト【Angularのユニットテストの基本とComponentの簡単なテスト編】 - Qiita
import {ComponentFixture, TestBed, async, ComponentFixtureAutoDetect,} from '@angular/core/testing'; import {By} from '@angular/platform-browser'; import {DebugElement} from '@angular/core'; import {AppComponent} from './app.component'; // describeでテストSuiteを作成 describe('AppComponentのテスト', () => { // テストの中のAppComponent let comp: AppComponent; // ComponentFixtureは、 componentのインスタンスそのものとcomponentのDOM
Vue.js の 単体テストについて、webpackなどビルドツールがない状況での環境を構築する - Qiita
背景 公式の単体テストでも、ビルドツールありきのテスト環境となっている。 ただ、自分の環境では、webpackなどビルドツールは使用しておらず、Vue.js の単体を使用している。 そんな状況だが単体テストは行いたい。 問題 公式でもwebpackなどを使用しているためか、vueのテストの情報は、ビルドツールありきになっている。 ただ、単体テストのためだけにwebpackを入れるか？ となるとそれはそれで、めんどくさい。 ちょろっと作ったvueアプリケーションの整合性が担保できればそれでいいので、できる限り手間をかけずにテストを行いたい。 達成目標 webpackは使わない. jasmine + karma での vue.js の単体テスト ヘッドレスなテスト (phantomjs使うよ) coverageは取れるようにしておく と以上の４点が達成できればOKということにします。 テストを
BrowserStack と Karma でクロスブラウザテスト環境を作る - Qiita
module.exports = function(config) { config.set({ browserStack: { username: "<your-username>", accessKey: "<your-token>" }, // base path that will be used to resolve all patterns (eg. files, exclude) basePath: "", // frameworks to use // available frameworks: https://npmjs.org/browse/keyword/karma-adapter frameworks: ["mocha"], // list of files / patterns to load in the browser files: [ "browser-sp
TypeScript + webpack + Karma + Mocha + Power Assertでテストを行う際の諸々の設定ファイル - Qiita
TypeScript + webpack + Karma + Mocha + Power Assertでテストを行う時の諸々の設定ファイル 最近、TypeScriptでコードを書いて、モジュールバンドラにwebpack、テストランナーにkarma、テスティングフレームワークにmocha、アサーションライブラリにPower Assertを使用したユニットテストを書いた その際に、諸々のツールが複雑で、設定ファイルの記述も大変だったので、ここで設定ファイルについてのメモを残しておこうと思う ※現段階では、設定ファイル自体にメモを書いただけです、後で個々の説明を書くかもしれません package.json まずはこれがないと始まらないですよね { // パッケージの名前 "name": "パッケージ名", // パッケージのバージョン "version": "1.0.0", // パッケージの説
JavaScriptのテスト環境構築(Mocha + power-assert + Karma + babel + webpack) - Qiita
この記事は、初めてJavaScriptのテスト環境を作ってみたおじさんによる、これからJavaScriptのテストを書いていきたいけど、登場人物が多すぎてなにやらめんどくさそうと思っている方に向けた記事兼備忘録です。 初めてのJavaScriptテスト環境構築で一応公式ドキュメントに目を通したけど英語の意味をちゃんと読み取れておらず、ツールやライブラリの理解や使い方が間違っている場合がありますのでアドバイスいただけると幸いです。 各テストツールやライブラリの紹介 JavaScriptのテスト環境を構築するときの一つ目の壁がツールやライブラリがたくさん出てきて、どれを使っていいかわからない/それぞれの役割がわからないことだと思う。 なので、まずはJavaScriptのテスト環境についてググったときに出てくる最近使われてそうな各ツールやライブラリの役割をすごく雑に紹介します。 テストフレームワ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPUnitのバージョンアップ(5.3.4→5.7.5)に伴うgetMock()の修正 - Qiita
初めてのPHPUnit - Qiita
PHPUnitのassertArraySubset()について - Qiita
Jest と ReactTestUtils で React Component のユニットテストを書く - Qiita
PHPUnit、Seleniumでエンドツーエンドテスト - Qiita
PHP5.3 対応でも PHPUnit は 6 スタイルの記述へ移行しよう - Qiita
PHPUnit + Guzzleで WebAPIのテストを書く - Qiita
Xamarin.Formsで単体テスト - Qiita
PHPUnitのテストコードを書くときによく使うイディオム - Qiita
