WebWorkerを手軽に扱うTransWorker v1.1でSharedWorkerが利用可能になりました！
photo credit: Pallet via photopin (license)
JavaScript において、メソッド呼び出し感覚で手軽に WebWorker によるマルチスレッドを扱える npmモジュール TransWorker を v1.1.0 に更新しました。
従来 DedicatedWorker にしか対応していなかったため、ワーカースレッドを生成したメインスレッドからしか扱えませんでしたが、 複数スレッドで共有できる SharedWorker が使えるようなり、ブラウザの異なるタブやウィンドウ間でワーカースレッドを共有できます。
その他、ちょっとした機能増強や不具合修正なども合わせて対応しています。
このページには、今回の変更点の概要、WebWorkerの基本事項、TransWorkerの使い方などを書いています。その他詳細はnpmのREADMEを参照してみてくださいね。
目次
関連記事：
TransWorker 更新内容 v1.0 => v1.1
SharedWorkerに対応【機能追加】
既に上で書いていますが、これまで DedicatedWorker にしか対応していなかったため、生成元のスレッドからしかワーカースレッドを扱えませんでした。
v1.1からは、複数スレッド間で共有できる SharedWorker が使えるようなったので、ブラウザの異なるタブやウィンドウ間でワーカースレッドを共有できます。
ワーカーからの通知のハンドラを後付け可能に【機能追加】
メインスレッド側でTransWorkerのインスタンスを生成するときに、ワーカースレッドからの通知を受け取るハンドラーをまとめて指定する形式をとっていましたが、インスタンス生成後に、個々の通知に対するハンドラーを設定できるように機能を追加しました（TransWorker.subscribe）。
メソッド呼び出し時の空のコールバックを不要に【不具合修正】
従来、メソッドの戻り値が無くてコールバックが不要な場合にでも、空のコールバック（()=>{} 等）を指定しなければいけなかったのですが、あまりにも不便でバグの元になっていたので修正しました。
引数リストの最後に関数オブジェクトが指定されていない場合は、コールバックは不要と判定します。 このチェックのため、動作速度に若干の影響があるかもしれません。 ほぼ体感できないレベルだとは思いますが、何らかの対策を考えたいです。
WebWorker について
※ここ、知ってる人は読み飛ばしてもらって結構ですよ。
WebWorkerはブラウザ上で動作するJavaScriptをマルチスレッド化するための仕組みですね。 メインスレッド（UIスレッド）からワーカースレッド（独立した実行コンテキスト）を生成し、スレッド間メッセージで通信できます。
DedicatedWorker と SharedWorker
ワーカースレッドには DedicatedWorker と SharedWorker という２つのワーカーが存在します（ServiceWorkerは別扱い）。
２つの違いは、その名前があらわしており "Dedicated" ＝「占有される」、"Shared" ＝「共有される」ということです。
つまり、DedicatedWorker は生成元のスレッドとしか通信できないのですが、SharedWorker は複数のスレッド間で共有され、各スレッドと通信可能なワーカーです。
例えばワーカースレッドで動作しているアプリケーションのコアロジックをブラウザの複数のタブやウィンドウから利用できるようになるわけです。
SharedWorkerの対応状況と制限事項
Chromeだけ？
せっかく SharedWorker に対応したのに、ざっと確認したところ、2018年12月現在 SharedWorkerがまともに動いているのは Chrome だけっぽいのです。 FirefoxではDedicatdWorkerと同様の動きをしており、EdgeやIE11では「SharedWorkerが見つかりません」と、にべもない。 Safari や Opera は未確認です。
ChromeのSharedWorkerではコンソール出力が使えない？
唯一SharedWorkerに対応しているように見える Chrome で、SharedWorkerの実行コンテキスト内から console.log が使えませんでした。 エラーにはなりませんが、何も出力されません（DedicatedWorkerでは出力されます。ただし大量に出力するとフリーズしやすかった）。
このため、後述の TransWorker で、SharedWorkerを使用している場合は、メインスレッド側へ転送して出力するようにしています。
TransWorkerの概要とサンプルコード
TransWorker は、WebWorker を手軽に利用するための npm モジュールです。
ワーカースレッドで実行したい処理をクラスのインスタンスメソッドとして定義 しておけば、メソッド呼び出しと同様の手順でマルチスレッドを利用できます。 スレッド間メッセージを意識する必要はなく、普通にJavaScriptのクラスを実装する感覚で実装できます。
メソッド呼び出しをスレッド間メッセージに変換
TransWorkerは与えられたクラスのインターフェースを読み取って、メソッド呼び出しをスレッド間のメッセージ通信に変換 します。
全てのメソッドは非同期メソッドとなり、各メソッドの戻り値はコールバック関数で受け取れます。
以下に最もシンプルなサンプルを示します。もう少し複雑なサンプルはコチラにあります。
foo-bar.js
以下のクラス はひとつの値を保持するクラスで、値を設定するメソッドと、読み取るメソッドが定義されています。 これら2つのメソッドはワーカースレッドで実行されます（実際にはコンストラクタもですね）。 特別にマルチスレッドで処理したいことではありませんがサンプルなのでご容赦を。
function FooBar() { this._value = null; } FooBar.prototype.setValue = function(value) { this._value = value; }; FooBar.prototype.getValue = function() { return this._value; };
index.html
WEBページでは、TransWorker、FooBarクラスと、次に説明するメインスレッド側のスクリプトを読み込んでいます。 バンドラーでまとめる場合は別な形式になると思いますが、とりあえずサンプルはシンプルに書いています。
<html> <script src="path/to/the/transworker.js"></script> <script src="foo-bar.js"></script> <script src="main-thread.js"></script> </html>
main-thread.js
メインスレッド側のスクリプトです。
FooBarのコンストラクタを与えてTransWorkerを生成し、それを通じてFooBarのメソッドを呼び出します。 この呼び出しはTransWorkerによってスレッド間通信に変換され、ワーカースレッド側のFooBarのインスタンスメソッドを呼び出します。 この戻り値は、コールバックで受け取ります。
//メインスレッド側ではワーカースクリプトとクラスの //プロトタイプを参照して生成する const fooBarWorker = TransWorker.createInvoker( "./worker-thread.js", FooBar); fooBarWorker.setValue("Baz"); //戻り値が無いのでコールバック不要 //FooBar.getValueの戻り値はコールバックで受け取る fooBarWorker.getValue(value => { console.log(value); // > Baz });
woker-thread.js
ワーカースレッド側のスクリプトです。FooBarのインスタンスを指定してTransWorkerのワーカー側インスタンスを生成しています。
importScripts(
"path/to/the/transworker",
"./foo-bar.js");
//ワーカースレッド側ではFooBarのインスタンスを利用
TransWorker.createWorker(new FooBar());
ワーカースレッド側からの通知
また、ワーカースレッド側から（メソッド呼び出しの戻り値ではなく）能動的な通知も行えます（TransWorker.postNotify）。 SharedWorkerを使っている場合、この通知は共有するすべてのスレッドへブロードキャストされます。 ただし、ワーカーのどの通知を受け取るかは生成元または共有元の各スレッドで決定できます(TransWorker.subscribe)。
以下の例は上のサンプルを一部書き換えたものです。
foo-bar.js
function FooBar() { this._value = null; } FooBar.prototype.setValue = function(value) { this._value = value; //通知を発行する。 this._transworker.postNotify("valueUpdated", value); //_transworkerフィールドはTransWorkerのファクトリが //注入する、このインスタンスを保持するTransWorkerの //インスタンスです。 }; FooBar.prototype.getValue = function() { return this._value; };
main-thread.js
const fooBarWorker = TransWorker.createInvoker( "./worker-thread.js", FooBar); // "valueUpdated"通知を受け取る fooBarWorker.subscribe("valueUpdated", value => { console.log(`valueUpdated ${value}`); }); //valueUpdated通知が発行される fooBarWorker.setValue("Baz");
API
メインスレッド向け
- (static) createInvoker - DedicatedWorker用のインターフェースを生成する。
- (static) createSharedInvoker - SharedWorker用のインターフェースを生成する。
- subscribe - ワーカーからの通知を購読する。
ワーカースレッド向け
- (static) createWorker - DedicatedWorker用のインスタンスを生成する。
- (static) createSharedWorker - SharedWorker用のインスタンスを生成する。
- postNotify - メインスレッドへ通知を送信する。
リンク
ここに記述していること以外の詳細、モジュール自体の使い方や、サンプルプログラムなどについては、以下 npm や GitHubリポジトリのREADME、またGitHub.IoのAPIドキュメントに記述してあります。
祝！SHARP MZ-700シリーズ発売36周年！な思い出話とエミュレータのお話です
自分にとっての最初のコンピュータ SHARP の 8ビットマイコン MZ-700 シリーズが 1982年11月15日に発売されて、今日でちょうど36年経ちました。 おめでたいので、当時からの思い出話などつらつら書いてお祝いしようと思います。
当時は、まさか36年後に、こんなお祝いしてるだなんて思ってもいませんでした。 当たり前ですけど当時はインターネットも携帯電話もハードディスクも普及していません。 ボクらにとってのメジャーな媒体はカセットテープでしたから！10分かけてゲームをロードしてたんだよー（笑） こんなに便利な世の中になったのは、みんなのおかげ。いろんなものに感謝・感激しておきたいです！おめでたい！
本日も、はてなブログで毎年MZ-700の発売記念をお祝いしていらっしゃるすぎもとさんのブログの記事を思わずTwitterでシェアしたら、たくさんの「いいね」をもらって、リツイートしていただきました。
“MZ-700発売36周年おめでとうございます - 祝！MZ-700発売36周年ブログ” https://t.co/AQcWcxeOlz
— たかみん (@_takamin_) 2018年11月15日
なんだかすぎもとさんのふんどしで相撲を取ってるみたいで申し訳ない気分でもありますので、ご本人のツイートをRT。かのブログはすぎもとさんのブログですのでー。
この世に生まれて３６年！
— すぎもと (@BGM) 2018年11月14日
どうにも無敵の７００だあ（だあ）！ pic.twitter.com/1cRCKxT3Uj
なにより平成最後のこの秋に、MZ-700を覚えている人がたくさんいるってことが、うれしい・楽しい・素晴らしいですね！
レジェンドパソコンゲーム80年代記
posted with amazlet at 18.11.15
佐々木潤 レトロPCゲーム愛好会
総合科学出版
売り上げランキング: 239,995
総合科学出版
売り上げランキング: 239,995
初めてのマイコンMZ-700との出会い
今から36年前。ワタシが中学二年の12月。父がMZ-731を買ってきました。プロッタプリンタがついている奴ですね。
父は仕事で使うために買ったのだとおもいますが、結局兄と私がほぼ占有することになっていました。
そんなこんなで自分にとって一番印象深い過去のマシンは未だにコレがトップです。
MZ-700のおかげ様
中学生の時にほぼ毎日プログラムリストとにらめっこしたおかげで、BASICやZ80のアセンブリ言語を覚えました。
一時期マイコンからは離れていましたが、数年後、成人してからソフトウェア企業へもぐりこむときに役立ちました。
その時まで、まさかコンピュータのプログラムを書くことが仕事になるとか思っていなかったんですよね。自分にとっては遊びでしたから。
その後ソフトウェアのエンジニアとして大成功こそしていませんが、紆余曲折とかありつつも、それなりに幸せに、それなりに楽しく暮らせているのも、このマシンのおかげといって過言ではないと言い切りたい。
フルJavaScriptエミュレータ
ここ数年は、あくまでも趣味の範疇でブラウザで動くJavaScriptによるエミュレータを作って公開しております。 業務上JavaScriptを多用しており、最近のブラウザならZ80のエミュレーションとか平気でできるのではないだろか？と思ったのがきっかけでした。
とはいえ、そんなに簡単にはいかず。約1年半で「MZ-700のエミュレーションやってます」と胸を張って言える状態まで持っていって、つい3か月ほど前にv1.0をリリースした次第。
お久しぶりです（笑） MZ-700 フルJavaScriptエミュレータ！
— たかみん (@_takamin_) 2018年8月26日
やっとv1.0のリリースです。ここ数年はエミュレーション自体は安定していて、UI周りをいじってばかりで、いい加減にしろよってことでね（笑）#SHARP #8bit #RetroPC #MZ700 #JavaScript #Emulator #NodeJs #npm https://t.co/fBeRn4SWVw
そのうち手を入れますのでゴメンナサイ
しかしこのあとまた放置。本業のほうがなかなかややこしい状況というのもあって、なかなか手が付けられません。
10月にリリースされた ChromeのVer.70で、「Audio API の使用はユーザー操作によって許可しないといけません」てな制限がかかるようになったのですが、これも手付かず。 ページを開いていきなり音が出るのを防ぐためなんですね。 この制限、4月か5月に一度リリースされてましたが上手く周知されていなかったようで世界中から猛反対に遭いGoogleさんが引っ込めちゃった。 Googleさんが引っ込める前に慌てて対策していたのですが、引っ込められて余計にややこしくなったので、こちらもロールバックしてしまい、そのコミットがどっかいっちゃいましたねえ。まいりました。
キャラグラの世界
先日、前述のすぎもとさんのブログで、キャラグラのMZTファイルが公開されていました（MZTはMZシリーズで読み込み可能なファイル形式です）。
せっかくなので、これをダウンロードして拙エミュレータで実行してみましたが、動きません。
メモリアクセスの関連でエラーになっていましたので、こちら側の不具合ですね。
この良き日にバグを見つけて残念ですけど、今から泣きながらデバッグしようと思います。
てな感じで普段の記事とは雰囲気が違っていますが、自分にとって、とっても大切な日でしたよってことで、それでは！
リンク
非同期処理の直列化：今やArray.reduceを使わなくてもできますよね
photo credit: hans-johnson 700-7000 Series_1 via photopin (license)
非同期処理の直列化とは「複数の非同期処理を、順番に実行する処理」のことです。非同期処理の順次実行や逐次実行とも呼ばれます。 処理速度は、並列処理よりも遅いのですが、処理順が重要であったり、先に実行した非同期処理の結果を次の非同期処理に使用する場合に必要になります。
JavaScriptでの非同期処理の直列化のやり方を検索すると「Array.reduce を使えばできる」とよく出てきます。
しかしアレ、そんなに便利ですかね？
コードが直感的じゃないし、ぱっと見ナニやってるのか分かりにくい。処理効率もそれほど良くなさそうです。
なんかもう「他のやり方ではできないよ」って誤解しそうな勢いですが、そうじゃない。 ES2017(ES8)以降のJavaScriptならもっとシンプルに書けますよね。
確かに「目的外使用」的で、軽く目からうろこが落ちて、「なるほどイイね！」と思う気持ちは理解できるのですが、それよか「誰にとっても直感的でわかりやすいコードを書く」ほうが重要ではないかと思ってます。
実際MDNでも、 reduceを使った直列化のコード が紹介されています。でも「こうすればできる」は「こうするべき」ではないですよね。
Vue.js入門 基礎から実践アプリケーション開発まで
posted with amazlet at 18.11.14
reduce使わずどうするか
じゃあreduce使わずにどうするの？っていうと、単純にfor ループで async / await を使えば普通に書けます。
for～of 文ならもっとラク。reduce よりも明らかに簡潔です。
async/awaitが使えないならreduceを使うしかなさそうですが、そんなレガシーな環境で動かしたいなら Babel で変換すればよろしいのです。
※ ちなみに、Array.forEachでループを回すと並列処理になってしまいますので使えません。
for～of で非同期処理を直列化するコード
以下、ちょっと長くなっていますが、MDNのreduceのページで紹介されているreduceを使った直列化のコード に for～of を使った同等の処理を追加しました。
/** * for～of を使ってPromise配列をチェインしながら実行する。 * （下のreduceバージョンと比べて如何に簡潔か確認） * * @async * @param {array} arr - Promise配列 * @return {Object} Promiseオブジェクトを返す */ async function runPromiseInSequenseByForOf(arr) { let res; for(const currentPromise of arr) { res = await currentPromise(res); } return res; } /** * reduce を使ってPromise配列をチェインしながら実行する。 * * @param {array} arr - Promise配列 * @return {Object} Promiseオブジェクトを返す */ function runPromiseInSequense(arr) { return arr.reduce((promiseChain, currentPromise) => { return promiseChain.then((chainedResult) => { return currentPromise(chainedResult) .then((res) => res) }) }, Promise.resolve()); } // promise function 1 function p1() { return new Promise((resolve, reject) => { resolve(5); }); } // promise function 2 function p2(a) { return new Promise((resolve, reject) => { resolve(a * 2); }); } // promise function 3 function p3(a) { return new Promise((resolve, reject) => { resolve(a * 3); }); } const promiseArr = [p1, p2, p3]; // Reduceバージョンで直列化 runPromiseInSequense(promiseArr) .then((res) => { console.log(res); // 30 }); // For～of バージョンで直列化 runPromiseInSequenseByForOf(promiseArr) .then((res) => { console.log(res); // 30（結果は同じ） });
これ見て、どっちが良いかって考えると、どう考えても for～of のほうが良いと思うんですよね。
ただ、関数型プログラミングに傾倒している人にとってはletで宣言した変数resを逐次更新するところが気持ち悪いのかもしれません。
C#のActionクラスとFuncクラスを理解する
photo credit: ARMLE Action ! via photopin (license)
C#でメソッドや関数を表す 2つのクラス Action と Func について説明します （全くの余談ですが、C言語的には関数ポインタ、JavaScript的にはFunctionオブジェクトに相当するものです）。
2つの違いは戻り値の有無。戻り値なしが Action で、戻り値ありが Func です。
どちらもジェネリックパラメータとして関数のパラメータリストを指定できるジェネリッククラスです。 ジェネリックパラメータを指定しない場合は引数無しの関数を表すことになります。
以降、それぞれの詳細な使い方について説明します。
※ この記事は、もともと「C#のラムダ式はAction・Funcと一緒に理解を深めるとヨロシイようで」で書いていた内容です。長ったらしいのでこちらに独立させました。
目次
Action クラス
C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング
posted with amazlet at 16.09.22
Actionクラスは「戻り値のない処理を記述するためのクラス」です。
Actionだけなら引数もなし。
// 引数無しのActionをラムダ式で生成
Action action = () => {
foo.bar();
};
引数が必要ならAction<引数の型リスト>を使用します。
例えば、
//引数を取るActionをラムダ式で生成 Action<string, int> action = (name, age) => { Console.WriteLine(string.Format( "{0} is {1} years old.", name, age)); };
てな感じです。
このように、インスタンスを作ること自体は難しいことではありませんが、誰かが作った既存のメソッドがActionクラスの引数を要求している場合、この逆の考え方、つまり、そのメソッドの定義を見て「何を与えればよいのか」をきちんと理解する必要がありますね。
覚えること ☞「Actionクラスは戻り値のない関数。ジェネリックパラメータは引数リストの型を表しています。」
Func<TResult>クラス
アップタウン・ファンク feat. ブルーノ・マーズ
posted with amazlet at 16.09.22
Funcは戻り値があるメソッドを表します。戻り値がboolで、引数のないFuncは、以下のように記述します。
//戻り値がboolのFuncをラムダで生成 Func<bool> func = () => { return true; };
引数が必要な場合は、Actionと同じくジェネリックパラメータで型を指定します。
//戻り値がboolで引数付きのFuncをラムダで生成 Func<string, int, bool> isAround50 = (name, age) => Console.WriteLine(string.Format( "{0} is {1} years old.", name, age)); if(45 <= age && age < 55) { return true; } return false; };
これがたとえば、メソッドのパラメータだとしても、考え方は同じで、以下のように書くわけです。
Task<bool> task = new Task<bool>(() => { return execute.Invoke(); }); chainedTask._task.Start();
Lambda式は、ActionかFuncクラスのインスタンスを生成していると考えられます。 このため、Lambda式だけを見て、どちらの型なのか推測するクセをつけておくと、混乱が少なくなる気がします。 ようするにしっかり理解しておきましょうということですが。
上の例では、Task<bool>のコンストラクタの第一引数の型は Func<bool> だと推測できますね。
そのほか無駄話など
Func<void>ではダメなんですか？
個人的な好みとしてですが、戻り値の有無でクラスを分けずに、Func<void>を認めて、Actionクラスはなくてよいでしょと思っています。
しかし、そもそもジェネリックの型パラメータにvoidは無理なのかもしれませんね。
VBでもFunctionとSubに分かれているし、マイクロソフトさんは昔から分けたい派なのかと思っていたけど、言語的制約なのかもしれません。
mocha を使った npm のユニットテストをブラウザで動かす設定
photo credit: wuestenigel White Cup with Coffee Grains via photopin (license)
mochaとchaiを使ったnpmのユニットテストをブラウザで動かすための設定をご紹介。
mochaにはブラウザで動作させる機能が備わっていますが、テストスクリプト以外にHTMLも用意しなくてはならないので少し億劫なんですよね。
実際には、ほぼ定型のHTMLなのですが、結構情報が少なくて「これで決まり！」みたいなのがない感じ。 コンソールとブラウザでスクリプトを共有したい場合に、問題が出て途方に暮れたこともありました。
ところが最近、ゆる～く試行錯誤を繰り返した結果、自分なりのテンプレートみたいなのが出来上がりつつあるので、ここに書いておきますよっと。
これとは逆に、WEBブラウザ向けESM(ESモジュール)のmochaのスクリプトをNode.jsでテストしたい場合の設定は、以下のページに書いています。
目次
ブラウザで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
