GitHubExampleテスト自分がそう呼んでいるだけなので、正式名称があるのかよくわかりませんが、あるライブラリを公開する際に、exampleディレクトリにそのライブラリを使って実際に動くサンプルコードを作って、それを実行するテストというのを示しています。Go言語のExampleと近いような気がします。Language以下のスライドでも簡単に解説してますが、この記事はExampleテストのメリットやNodeモジュールでのやり方について書いていきます。以下は思いついたExampleテストの良いところですが、これについて簡単に解説します。多くの人はライブラリを書いたらREADMEにサンプルコードを載せたりすると思います。それを実際のファイルとして作れば大体Exampleテストのやることは完了です。典型的なExampleテストの作り方は以下のような感じです。ローカルモジュールでテストしたいライブラリを読み込むライブラリを使ったサンプルコードを書くコマンドで見ると以下のような感じですね。example.jsこうして作ったexample.jsを実行した結果が正常終了ならば、Exampleテストをパスしたという単純なものなので特別なテストフレームワークなども不要で導入は簡単だと思います。testなどで実行するようにすればExampleテストができます。},また、ロジックテストを書くことが難しいライブラリでも、単純に実行するだけなら書くことは簡単で少なくても実行して例外がでないというチェックを簡単に取り入れることが利点の一つです。ローカルモジュールを使うことで、サンプルコードからrequire("../lib/some")のような相対パスが不要になります。node_modules以下にインストールされるので、ユーザーがライブラリを使うのと同じようにrequire("some")と書くことができます。azu/browser-runnerのExampleテストではローカルモジュールとして本体のライブラリを読み込んでいるため、browser-runner/example.jsには相対パスが出てこないようになっています。EXAMPLE!");}).catch(console.error.bind(console));つまり、ユーザーがコピペで動かせるようなサンプルコードが作れる事につながります。実際に動かせるサンプルコードはドキュメントとしても役立つのでExampleテストはドキュメント的な性質もあるかもしれません。testとかで実行するようにするだけで、CIとかでも自動的にExampleテストが走るので便利です。publishされるため、publishしたものにファイルが入ってなかったりそういうミスは結構多いです。publishのパターン的なものを使ったりdependency-checkなどでチェックしたりすることである程度カバーできます。Exampleテストをするときにローカルモジュールとしてインストールして試せば、実際にその時点のpackage.jsonが使われるのでpackage.jsonのミスに気付きやすくなります。"bin"のパスが間違ってたりするとExampleテストからコマンドを叩こうとするテストを書いておけば例外が起きるのでパスの間違いに事前に気付くちゃんとが増えるといった感じです。おわりにExampleテストはサンプルコードを実行した結果が正常終了であるという前提のため、異常系など全部をカバーするのは難しいと思います。いうのはロジックテストなど普通のテストでやるほうが楽で、両方できるとカバー出来る範囲は広がります。テストを書くのが難しそうなものであった場合にとりあえずexampleだけでも書いて実行できるようにしておけば、結構安心感がでるのでオススメです。タグ:npmtestingJavaScriptNode.jsお知らせ欄JavaScriptに関する最新情報は週一でJSer.infoを更新しています。efcl/efcl.github.ioからご意見下さい関連記事コメントを。