銀の弾丸

プログラミングに関して、いろいろ書き残していければと思っております。

mocha を使った npm のユニットテストをブラウザで動かす設定

f:id:takamints:20181110123153j:plain
photo credit: wuestenigel White Cup with Coffee Grains via photopin (license)

mochaとchaiを使ったnpmのユニットテストをブラウザで動かすための設定をご紹介。

mochaにはブラウザで動作させる機能が備わっていますが、テストスクリプト以外にHTMLも用意しなくてはならないので少し億劫なんですよね。

実際には、ほぼ定型のHTMLなのですが、結構情報が少なくて「これで決まり!」みたいなのがない感じ。 コンソールとブラウザでスクリプトを共有したい場合に、問題が出て途方に暮れたこともありました。

ところが最近、ゆる~く試行錯誤を繰り返した結果、自分なりのテンプレートみたいなのが出来上がりつつあるので、ここに書いておきますよっと。

テスト駆動開発
テスト駆動開発
posted with amazlet at 18.11.10
オーム社 (2017-11-13)
売り上げランキング: 7,425
目次

ブラウザでmochaのテストを行う為のHTML

以下はユニットテストブラウザーで動かすために必要なHTMLファイルです。

test/web-test.html

<!DOCTYPE html>
<html>
    <head>
        <title>npm run web-test</title>
        <link rel="stylesheet" href="../node_modules/mocha/mocha.css" />
    </head>
<body>
<h1>npm run web-test</h1>

<div id="mocha"></div>

<!-- mocha の読み込みとセットアップ -->
<script src="../node_modules/mocha/mocha.js"></script>
<script>
    mocha.setup('bdd');
    mocha.setup('tdd');
</script>

<!-- テストスクリプトを読み込む -->
<script src="./web-test.js"></script>

<!-- テストの実行 -->
<script>
    localStorage.debug = "*"; //npm debug向けのデバッグログの設定。
    mocha.run();
</script>

</body>
</html>

mochaの公式ページに掲載されているHTMLファイル(→RUNNING MOCHA IN THE BROWSER - mocha)をもとにしており、npm の開発環境にインストール(npm install --save-dev mocha chai )されているモジュールを利用するように変更しています。

元ファイルでは mocha と chai の外部スクリプトCDNから読み込んでいますが、mocha は node_modules 以下のファイルを読み込むようにして、chai はJS側で取り込みます(理由は次項で)。

debug モジュールのすゝめ

必須ではありませんが、上の例では見やすいログを出力する debug モジュールの設定をしています。 ブラウザではF12ツールのコンソールに色がついて見やすくなります。 WebではlocalStorage.debugに、出力したいロガーの名前をカンマ区切りで指定しておきますが、上の例では "*" としていますから、すべてのログが表示されます(mochaもdebugを利用しています)。

ブラウザで動作するmochaのテストスクリプト

chai は テストスクリプトで require する。

前述のように、元ファイルでは chai をSCRIPTタグで読み込んでいますが、自分的にはコンソールから実行するものと同じように、テストスクリプトで取り込むようにしています。 こうしておくことで、コンソールで実行するテストスクリプトのうち Node.js特有の機能を使っていない物をブラウザでも実行できるようになるからです。

しかし、これによってテストスクリプトをバンドラーでコンパイルしなくてはなりません。 これについては後述しますが、設定なしの Parcel を使えば簡単です。

ユーザー操作を待つテストの書き方

テストの実行時に、ボタンのクリックなどの操作を待つ必要がある場合は、その操作で解決する非同期関数を用意し、テストの中から呼び出しますようにします。 この場合、mochaのテストのタイムアウトを無効にしておく必要があります。

以下の例は、ボタンがクリックされてからテストが実行されます。

例)ユーザー操作を待つテストスクリプト

"use strict";
const assert = require("chai").assert;

/**
 * ボタンを作って押されたら解決するPromiseを返す。
 * Promiseは30秒後にリジェクトされる。
 * @returns {Promise} Promiseを返す。
 */
const buttonClicked = (() => (new Promise( (resolve, reject) => {
    const button = document.createElement("BUTTON");
    button.innerHTML = "Click to go";
    button.addEventListener("click", () => resolve() );
    document.body.appendChild(button);
    setTimeout(() => {
        document.body.removeChild(button);
        reject(new Error("The user operation timeout"));
    }, 30000);
})));

//テストターゲット
const foo = () => "bar";

//ユニットテスト
describe("foo", () => {
    it("should be bar", async () => {//非同期関数とします
        await buttonClicked();         //ボタンが押されるまで待つ関数

        assert.equal( foo(), "bar" );

    }).timeout(0);  //タイムアウト無効
});
  • 待ち時間が30秒を越えるとエラーを投入するのでテストは失敗します。
  • クリックするためのボタンを動的に追加していますが、あらかじめHTMLに書いておいても構いません。

npmのscriptsを設定する

テストに限らず、何らかのコマンドの実行は npm の scripts を使うと便利です。 node_modules 以下にあるモジュールのコマンドはパスの指定をせずに使えますから。

ここでは一例として、npm run web-test でブラウザでのテストを実行するよう設定し、 npm test または npm run test で通常のコンソールでのテストを実行するようにしています。 この辺はお好みに応じて変更してください。

package.json(一部):

"scripts": {
    "test": "mocha",
    "web-test": "parcel test/web-test.html --open",
    ・・・
    },

Parcel のすゝめ

ブラウザでのテストは、Parcel だけで 「バンドル」 → 「Webサーバー起動」 →「 ページを開く」 までを一気にやっています。 Parcelめっちゃ便利です。ブラウザーでのテストのためだけに使っても良いかも?って思っています。 BrowserifyやWeb-Packでは、いろいろ細かな設定が必要になるはずです。

ページを開いたときの実行時エラー 「regeneratorRuntime is not defined」を解消する

Parcelを使うとBabelも使うことになりますが、そのままだとブラウザでの実行時に以下のようなエラーが出ることがあります。

Uncaught ReferenceError: regeneratorRuntime is not defined
    at Suite.<anonymous> (test-script.js:38)
    at Object.create (mocha.js:720)
    at context.describe.context.context (mocha.js:532)
    at Suite.<anonymous> (test-script.js:7)
    at Object.create (mocha.js:720)
    at context.describe.context.context (mocha.js:532)
    at Suite.<anonymous> (test-script.js:6)
    at Object.create (mocha.js:720)
    at context.describe.context.context (mocha.js:532)
    at Object.parcelRequire.transworker.js.chai (test-script.js:5)

このエラーはBabelで変換対象となるような比較的新しいコードがあるときに発生するように思います。

解消するには、以下のような babel-polyfill だけをインポートするスクリプトを用意して、HTMLのSCRIPTで、テストスクリプトよりも前に読み込みます。ポリフィルはWebページから一度だけ参照すべきなので、このような対処になります。

test/babel-polyfill.js

require("babel-polyfill");

test/web-test.html

<!-- ポリフィルを読み込む -->
<script src="./babel-polyfill.js"></script>

<!-- テストスクリプトを読み込む -->
<script src="./web-test.js"></script>

コンソールでブラウザ向けテストを除外する

細かなことですが、コンソールでもテストを行っている場合は、 ブラウザ特有の機能を使っているテストスクリプトを除外してやる必要があります。

これは、mocha.opt というファイルで行います。 以下の例では、testディレクトリ内のファイル名が'web-'で始まるファイルを除外しています。

test/mocha.opt

test/!(web-)*.js

リンク

あなたが正しくウェブページのカーソル形状を変更するには

f:id:takamints:20181101110252j:plain
photo credit: Maria Eklind Frankie & Benjys bookstore and theatre Reggiano via photopin (license)

なにやら暑苦しいタイトルで失礼します。

ここにはウェブページのマウスカーソルの形状を変更するにはどうすればってことを書いてます。

「何を今さら」って感じですけど、先日、目からウロコが3つほど落ちましたので書いておきます。

小ネタといえば小ネタです。

目次

ページ全体のカーソル形状を変更する

ページ全体でマウスカーソルの形状を「待ち状態」にしたいことがありますね。 勝手に手が動くぐらいの勢いで以下のようにしていましたし、ググってみてもこのように説明されてるページが多いです。

でも、これ厳密には不完全なんですよ。

document.body.style.cursor = "wait";

何がダメかって言うと、WEBページのコンテンツが短い場合です。

コンテンツが少ないと、画面の下のほうにカーソル形状が変化しない領域が残ってしまうのです。

BODY要素(=document.body)はブラウザ画面の全体に広がっているとは限らないということです。 スタイルシートがどうなってるかにもよりますけどね。

で、これを回避するのは実に簡単。BODYじゃなくてHTMLのスタイルを変更します。

document.body.parentElement.style.cursor = "wait";

document.bodyの親要素はHTMLです。document.documentElement もHTML要素を指すそうですが、ブラウザ間の実装に違いがあるかもしれないので注意が必要。

以下のボタンを押すとHTMLのカーソル形状を変化させます。

コントロールは親要素のカーソル形状を継承しない

下のフォームのボタンを押すとBODYのカーソル形状をWaitカーソルに変えます(5秒後に元に戻ります)が、 各コントロールの上へカーソルを持って行っても形状は変化していません。 ChromeFirefoxではLABELのカーソル形状も変化しません(Edgeでは変化しました)。





既定の形状に戻すのはdefaultではない

一時的に変化させたカーソル形状を元に戻す場合、default に設定しなおしていましたが、これでは全てが矢印になっていました。

ほとんどの要素の既定の形状は矢印ですが、そうでないのもありまして。 例えばテキストボックス(<input type="text"/>)は縦線みたいなのが既定の形状。

const foo = getElementById("foo");
foo.style.cursor = "wait";
(長めの処理)
foo.style.cursor = "default"; //← 全部矢印になっちゃいます

といっても、すべての要素の既定のカーソル形状を覚えておいて、それぞれ個別に元に戻すなんてナンセンス。

じゃ、どうするか。defaultじゃなくautoにすればよいのです。

const foo = getElementById("foo");
foo.style.cursor = "wait";
(長めの処理)
foo.style.cursor = "auto"; // ← 要素ごとの既定のカーソルに戻ります。

ちなみに、最近のブラウザでは initial でも元に戻っているようです。 これはHTML5で規定されているのかもしれませんが、IE11では効きませんから、やっぱり auto でよいみたいです。

default / initial / auto でそれぞれ意味が違うのでしょうから、ややこしいですね。

EdgeがIMGタグのSVGをストレッチしてくれないことがある

f:id:takamints:20181014160024p:plain

HTMLのIMGタグでSVG画像を表示するとき、EdgeではSVG画像がIMGタグのサイズに拡大・縮小されず、SVGで指定されたサイズでそのまま表示されることがあります。

他のブラウザ(ChromeFirefoxSafari)では大丈夫でした。 また他の画像形式ならばEdgeでも問題ありません。

どうやらEdgeでは、SVGのサイズ指定方法によって表示が変わるようです。これが不具合なのかどうなのかはわかりません。

このようにEdgeはちょっと邪魔くさいことが多く、ブラウザシェアも6%程度(2018年9月現在の日本国内シェア)のようなので、できれば無視したいのですが、Windows 10の標準バンドル品なので、無視しがたいのが悩み所・・・。

※ 本記事で確認しているEdgeのバージョンは42。レンダリングエンジンEdgeHTMLのバージョンは17。


目次

SVG関連の記事:

takamints.hatenablog.jp

takamints.hatenablog.jp

発生する現象

下の画像は、9×9のクロスハッチで、SVGのサイズは1215×1215pxのSVG画像です。 Edge以外では正しく表示されているはず。

gray-9x9-crosshatch-1215x1215.svg:

<img width="270px"
  src="https://takamin.github.io/images/gray-9x9-crosshatch-1215x1215.svg"/>

Edgeでは下のように表示されてしまいます。 IMGタグの領域内にオリジナルのスケールで表示されています。

原因

SVGファイル内での画像サイズの指定がstyle属性で行われていると、(Edgeだけで)この現象が発生するようです。

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   style="width:1215px; height:1215px;"
   viewBox="0 0 321.46874 321.46876"
   version="1.1"
   .
   .
   .

対策

SVGファイルのSVG要素のサイズ指定をstyleではなくwidthと height で行えばEdgeでも正しく表示してくれます。

※ widthとheight属性でサイズ指定していても、styleでサイズが指定されていれば、スケーリングされないようです。

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   width="1215px"
   height="1215px"
   viewBox="0 0 71.437498 71.437502"
   version="1.1"
   .
   .
   .

以下は属性だけでサイズ指定したSVGです。Edgeでも正しく表示されているはずですよ。

<img width="270px"
  src="https://takamin.github.io/images/gray-9x9-crosshatch-1215x1215-edge.svg"/>

他の対策

他の対策もありますので以下に書いておきますね。

style属性を書き換える

SVGのstyle属性でサイズを指定していても、表示したいサイズに変更すれば問題ありません。 しかしこれだと、大きなサイズの画像を縮小してサムネイル的に表示したいときなどに、ファイルを分ける必要があり、SVGを使っている利点が出ません。

XHRでSVGを取り出して表示。

外部サイトのSVGファイルなどで編集できない場合などは、別途XHRでSVGを取り出して内容を編集してから表示する必要があるかもしれません。 この場合は、IMGタグではなくインラインSVGSVGタグ)で表示する手もあります。

何が正しいのかよくわからん

この挙動が、HTMLの仕様として正しいのかそうでもないのかは読み取れませんでした。 しかし、SVGの仕様では、style属性の中でwidthやheightを指定できるという記述は見つけられませんでした。

つまり、本来widthやheightはstyleで指定するものではないけれど、Edgeはそれを(良かれと思って?)解釈してくれて、上記のような挙動になっているのかもしれません。

リンク

developer.mozilla.org

developer.mozilla.org

developer.mozilla.org