フロントエンドテストにおける知見の宝庫を発見！「javascript-testing-best-practices」 - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Jest · 🃏 Delightful JavaScript Testing ドキュメント
スナップショット機能で大きなオブジェクトを容易に追跡できるテストを作成できます。スナップショットはテストと一緒に、あるいはインラインに埋め込んだ状態で表示できます。
Seleniumアレルギーのための処方箋 - Qiita
何年も前、SeleniumやWebDriverの話で盛り上がった記憶があります。ただ、その当時はまだRailsなどバックエンド中心の文脈でした。今、フロントエンドに軸足が移る中、ブラウザテストの状況はどうなったのでしょう? 不思議なことに、フロントエンド界隈でそれほど話題に上がって来ないですよね (私の周りだけ?)。結構大事なのに。実は皆さん、「Seleniumアレルギー」なんじゃないですか? 公式サイトに漂う ゼロ年代感(下図)。Javaへの躊躇、「めんどくさい」と聞かされ続けた過去、無意識に避けてしまうのがSeleniumです。 ただ、フロントエンドの文脈でこそ、ブラウザテストは重要度を増しています。そこで「Selenium触りたくない病」の筆者が、 四苦八苦した背景 と、2016年だからこそ 見えてきた落とし所 を書いてみたいと思います。 註: 思ったより長文になってしまいました。先
Chromeのヘッドレスブラウザがやってくる。というわけで試してみた。 - Qiita
注意：この記事は古いです。2016年06月06日に書いた記事です。 2017/04/14 追記： Chrome59から正式にヘッドレスモードが搭載されます。 ヘッドレスモードではPhantomJSなどのようにJavaScriptでヘッドレスブラウザを制御することも可能です。 https://chromium.googlesource.com/chromium/src/+/master/headless/ 2017/06/07 追記： NightmareJS風に操作できるライブラリをリリースしています。 ヘッドレスChromeをもっとも簡単に操作できると思われるNightmareJS風ライブラリ http://qiita.com/devneko/items/3689b46fc2bcdb8121a8 先日、Googleの人が「Headless Chrome is coming so soon」
step by stepで始めるKarma - Qiita
Karmaを使うことでフロントエンドの単体テストを楽しくかつ機能的に行うことができます。 ステップを通して少しづつ理解できるように執筆しました。 また、最後に重要だろうと思われる補足内容を記載しました。 Karmaの導入に一役買えれば幸いです。 テスト全体の流れについては以前書いた記事フロントエンドにテストを導入を参照してください。 Karmaとは ブラウザ上で 単体テストを実行するためのテストランナーです。 テストを実行するだけでなくファイルの変更監視や結果のレポートを出力してくれたりと単体テストに必要な機能が一通りそろっています。 特定のフレームワームに依存しておらず汎用的に使えるツールで、プラグインを使った機能の拡張が強力です。 前提 Nodejs,npm,chromeが導入済みであること 流れ Karmaは4つの大きな機能（プラグイン）が存在します。 Step 3 〜 Step 6
Nightmare v2(Electron) でブラウザ上でES2015のコードを個別にrequireしてユニットテストを書く - Qiita
'use strict'; // nightmare const Nightmare = require('nightmare'); const path = require('path'); const TEST_HTML_PATH = "file://" + path.join(__dirname, "test.html"); // create global.browser = null; let startBrowser = function * (){ global.browser = Nightmare({ show: false, nodeIntegration: true }); yield browser .goto(TEST_HTML_PATH) .wait('body') .evaluate(() => { require("babel-register"); //
benvを使ってangular.jsのコードをnode上で動作させる - podhmo's diary
はじめに テストなどを書きたい時にブラウザを立ち上げずに動作チェックなどをしたいことがある。 しかしangular.jsを直接nodeからrequireすると怒られる $ npm install --save angular $ node -p 'require("angular")' ReferenceError: window is not defined at Object.<anonymous> (/home/podhmo/tmp/angular-api-test/node_modules/angular/angular.js:29016:4) at Module._compile (module.js:435:26) at Object.Module._extensions..js (module.js:442:10) at Module.load (module.js:356:
テストがないJS環境にモダンなテスト環境を導入していく - Qiita
Qiita:Teamに投げた社内ドキュメントだったけど、特に問題ないのでQiitaにも投げる。 前提として browserify-rails とbabelify が導入されている状況を想定してる。 基本方針 新規コードはES2015で書く 本番はbrowserify(-rails)でコンパイルする。 単体テストは node 環境下で走らせる テスト環境下では jsdom で window, document をモックする 単体テストでは ブラウザ特有の挙動はテストしない 裏側の環境(browserifyやspec-helper)は難しくして良いが、利用者からみえる範囲は複雑にしない(npm install; npm testで走る) Universal JavaScript に寄せることでコードのポータビリティを上げる 事前準備 browserify-railsを導入する。 .babelr
ブラウザでビジュアルテストをするreftest-runnerを作った
概要 reftest-runnerというブラウザで描画内容やレイアウトといった表示結果をテストするためのライブラリを作りました。 要素技術としてはブラウザ、WebDriver API、レンダリングキャプチャ、画像Diffという感じです。 azu/reftest-runner 時間が無い人向け 以下のスライドに簡単にreftest-runnerやreftestとはなにか、どういうユースケースがあるのかが書いてあります。 reftest-runner-overview.pdf reftestとは reftest(Referrence Test)とは、2つのHTMLの表示結果(スクリーンショット)を比較することで表示結果が意図したものかをテストする方法です。 用意するHTMLとして以下の2種類を1セットとして用意して利用します。 テスト用HTML テストしたい機能を使って実装したHTML リファ
UIテストの自動化！Node.jsとSeleniumでWebアプリのUIテスト環境構築 – ICS MEDIA
ウェブアプリケーションを開発する際、みなさんはどのように動作確認（試験）を行っていますか？ ウェブアプリケーションは、ユーザーごとに異なるブラウザを使用しており、ユーザー操作も必要となるため、手作業でテストをされている方も多いと思います。また、機能改修やバグフィクス後に、リグレッションテスト（改修により既存機能への影響がないかを確認する回帰テスト）が必要となりますが、時間が取れず試験ができていない方も多いのではないでしょうか。 本記事では、これらのテストを自動化することのできる「Selenium Webdriver」（セレニウム・ウェブドライバー）について紹介します。 入力フォームのバリデーション機能をチェックするデモ 簡単な入力フォームのバリデーション機能をチェックするデモを動画で紹介しましょう。入力値に対して期待するエラー文言が表示されているかのテストを実施しています。Selenium
0からはじめるpower-assert - console.lealog();
テスト書いてないとかお前そ(ry すみません、言ってみたかっただけです。 そして本記事は、巷で話題のAdvent Calendarとも何の関係もありません。 来年こそは書いてみたい！ そもそも こんなたいそうなタイトルの記事ですが、 書いてる人がそもそもテストに関してぺーぺーなので、なんか変なコト言ってたら教えてください。 まず、根本的に勘違いしてたことがあるので、まずそれを記しておきます。 ※今思えば個人の勝手な勘違いです。 巷で話題のpower-assertですが、これだけ使えばもうテスト全ておっけー！ってものではないです。 そして、サクッと入れてサクッと使えるってものでもないです。 よーわからんけどテスト書いた方が良いって最近よく聞くし、 power-assertってのがとりあえずイケてるらしいから、それ使ってテストデビューしてみようかな・・って人。 それなりに前提知識がないと辛いで
GruntでJasmineを使ったHeadlessなユニットテスト
GruntではHeadlessなユニットテストを行うための Qunit があります。しかし、個人的にはRSpec風に記述できる Jasmine の方が読みやすいので、Jasmineでのユニットテスト環境を構築してみました。 まず、Grunt Jasmine runner をインストール [shell] $ cd /your-project $ npm install grunt $ npm install grunt-jasmine-runner [/shell] PhantomJSがない場合はBrewでいれておく [shell] $ brew install phantomjs [/shell] 自身のgrunt.jsファイルに追加 [js] // Jasmine jasmine: { // テストするためのソースファイル src : ‘path/to/project/*.js’, //
gulp + webpack + mocha + assertでブラウザとコンソール両方でテストするサンプル - Qiita
var gulp = require('gulp'); var gutil = require('gulp-util'); var webpack = require('webpack'); var WebpackDevServer = require('webpack-dev-server'); var webpackConfig = require('./webpack.config.js'); var open = require('gulp-open'); var mocha = require('gulp-mocha'); // default task is browser test gulp.task('default', ['browser-test']); // browser test gulp.task('browser-test', function (callba
5minで分かるpower-assert
power-assert 5分ぐらいでわかるpower assert power-assert power assert assert(a === b); のような単純なアサーションのみ必要十分 Assert失敗時(テストが通らなかった時)に分かりやすい情報を表示 沢山のアサーションを使い分けしなくていいというメリット そもそも何故アサーションの種類が豊富なのか? 例) Chaiのexpect 33コもアサーションメソッドが存在 expect('foobar').to.contain('foo'); contain 含んでないから失敗した 失敗した時に何故失敗したのかを表示することが出来る どうやって動いてるの? power assert !== アサーションライブラリ コードを変換したりするのでツールに近いテストツール Work flow テストコードをpower-assert用に変換し
GitHub - power-assert-js/power-assert: Power Assert in JavaScript. Provides descriptive assertion messages through standard assert interface. No API is the best API.
What is power-assert? is an implementation of "Power Assert" concept in JavaScript. provides descriptive assertion messages through standard assert interface. No API is the best API. With power-assert, you don't need to learn many assertion library APIs (in most cases, all you need to remember is just an assert(any_expression) function) Stop memorizing tons of assertion APIs. Just create expressio
QUnitの概要 - Qiita
QUnitとは JavaScript用のTestingFrameworkです。 由来 jQueryのテスト用に作られ、今もjQuery、jQuery-UIのテストに使われています。 それ自体はjQueryに依存していませんが、テスト内でDOMを操作したりイベントを生成したりするのにjQueryを使うと便利です。 JavaScript的な側面 実行環境 QUnitとテスト用のスクリプトをブラウザに読み込んで実行します。 テスト結果はそのままブラウザに表示します。 他のツールと連携すると PhantomJSを使えばCLIで実行可能 Testemを使うとテスト修正時の自動リロード（再実行）が可能 Gruntからもgrunt-contrib-qunitプラグインを使って実行可能 ちなみに、mochaというTestingFrameworkはnode.jsで実行します。 インストール npmで入れるこ
RailsでJavascript/CoffeeScriptをテストするときの決定版（にしたい）！Konacha - リア充爆発日記
というわけでKonachaです。https://github.com/jfirebaugh/konacha なにこれ、粉茶？ JavascriptのテスティングフレームワークとしてはJasmineやらMochaあたりがメジャーどころのようだけど、セットアップが難しかったりして「これだ！」というものがなかった。個人的には。 で、今回、よーし、お父さんCoffeeScript書いちゃうぞー！というタイミングにあたって、もう一回いろいろ探してみたところ、これが一番スジがいいっぽかった。 KonachaはRailsでMochaとchaiを使いやすくしたGemらしい。Mochaとchaiは使ったことなかったけど、公式を5秒ほどみたところ、nodeでうごくrspecライクなテスティングフレームワークということでJasmineとかとあんまかわらないんじゃないかと推測。chaiはマッチャーのライブラリのよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Jestの曖昧な比較 - Qiita
Jasmine使い方メモ - Qiita
JavaScript の簡単☆単体テスト（grunt + qunit） - Qiita
