Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

このコマンドで呼び出される、guess.js の処理はおおむね以下のように処理されています。 カレントディレクトリにある package.json の解析 テストディレクトリなどの設定取得 カレントディレクトリにある tsconfig.json の解析 TypeScript コンパイラオプションなどの設定取得 index.js にカレントディレクトリのパス、TypeScript コンパイラオプションの情報を渡し実行 テストを実行する際はほぼプロジェクトルートディレクトリで行われると思うので、カレントディレクトリはプロジェクトルートディレクトリに読み替えることが出来ます。 この時、手順 2においてプロジェクトルートディレクトリに tsconfig.json が存在しないため null が返ってきてしまいコンパイラオプションを取得できず、テスト実行に失敗してしまいます。 ローダの設定とテストの
mochaで、describeをネストして書くことが多いんですが、その時にhook関数がどういう順番で呼ばれるのか不安に駆られたので調べてみました。 テストコードはこんな感じです。行数削減のために詰めて書いているのでちょっと見難いですが、ご容赦ください。 const {expect} = require("chai"); before(function(){console.log("global before")}); beforeEach(function(){console.log("global beforeEach")}); after(function(){console.log("global after")}); afterEach(function(){console.log("global afterEach")}); describe("hook call order
この記事は、初めてJavaScriptのテスト環境を作ってみたおじさんによる、これからJavaScriptのテストを書いていきたいけど、登場人物が多すぎてなにやらめんどくさそうと思っている方に向けた記事兼備忘録です。 初めてのJavaScriptテスト環境構築で一応公式ドキュメントに目を通したけど英語の意味をちゃんと読み取れておらず、ツールやライブラリの理解や使い方が間違っている場合がありますのでアドバイスいただけると幸いです。 各テストツールやライブラリの紹介 JavaScriptのテスト環境を構築するときの一つ目の壁がツールやライブラリがたくさん出てきて、どれを使っていいかわからない/それぞれの役割がわからないことだと思う。 なので、まずはJavaScriptのテスト環境についてググったときに出てくる最近使われてそうな各ツールやライブラリの役割をすごく雑に紹介します。 テストフレームワ
power-assert is fully compatible with assert. So functions below are also available though they are not enhanced (does not produce descriptive message). assert.fail(actual, expected, message, operator) assert.throws(block, [error], [message]) assert.doesNotThrow(block, [message]) assert.ifError(value) API - power-assert/v1.3.1/README.md とあるように、assert.throwsはテスト失敗時に整形されません。
なんかどうも jsdom + power-assert + 自作の eater を使ってテストをしていたら espower-loaderが中で使っている source-map-support のモジュールがエラーになる。 エラーの場所はココ で、source-map-support の中で何やってるかというと、 error.stack プロパティがあるかどうかを見てるが、 stack を触った瞬間に下記のエラーになり、巻き込んで別な例外が出て死ぬ TypeError: Invalid URL Error /Users/furukawa.yosuke/Program/xxxxxxxx/node_modules/espower-loader/node_modules/source-map-support/source-map-support.js:388 var hasStack = (arg
assert-polyfill - an exterminate "TypeError: undefined is not a function" you encounter in node-v0. polyfillを作成しました。mocha.optsに定義するか、power-assertのrequire前に実行することで、deepStrictEqualとnotDeepStrictEqualが未定義の時だけ、アサート関数を定義します。 require('assert-polyfill'); var assert = require('power-assert'); assert.deepStrictEqual(['foo'], ['foo']) // pass assert.notDeepStrictEqual(['foo'], ['bar']) // pass
Angular1系で書かれてるプロダクトにテストを用意するにあたって環境の構築、実際のテストコードの作成など、色々調べたのでまとめていこうと思います。 前提環境 TypeScript(v1.8, 含テストコード) AngularJS(v1.4) karma+mocha+power-assert コードはイマドキのrequireからの依存解決してbundleするスタイルではなく、TypeScriptのnamespaceでスコープを区切ってtsc --outFile dist/bundle.jsのようにconcatした単一ファイルを吐き出す形です。 環境を再現したリポジトリ:https://github.com/sisisin-sandbox/ngts/tree/master/namespace-style 最低限karmaを動かせるようにする 色々ハマりましたが、最終的にはこちらの記事を参考
TypeScript初心者です。 Node.jsで開発して規模が大きくなってくると型が恋しくなってきますね。TypeScriptはVisual Studio Codeでの補完も効くし、コンパイラがくだらないミスを教えてくれるのでうっかりさんには嬉しいです。 しかし、素のNode.jsで使っていたツール達がそのまま使えないのがネックです。 Node.jsで使用していたmocha, power-assertをTypeScript@2.1.5で使うまでにえらく苦労したのでその軌跡です。 前提 JavaScriptはブラウザで動くフロントエンドの話と、サーバーサイドのNode.jsの話が混在していて情報が錯綜しやすいのですが、本稿はサーバーサイドのNode.jsに関する話です。 . ├── dist ├── node_modules ├── package.json ├── src │ └── i
サンプル https://github.com/iwata-n/nodejs_coverage node.js+expressで作ってるプロジェクトのテストでカバレッジを取りたかったので調べてみた結果をまとめておく。 gulp ビルドツールとしてgulpを使う。gruntも有るっぽいけどもgulpを使う。 カバレッジ取得ツール istanbulを使う。istanbulをgulpのプラグインとして用意してくれている人がいるので感謝 設定 gulp-istanbulのREADMEに従ってgulpfile.jsを用意する。 express-generatorが出してきたままなコードになっている。 var gulp = require('gulp'); var istanbul = require('gulp-istanbul'); var mocha = require('gulp-mocha'
gulp-mochaとistanbulを使ってローカルでコンソールにテスト結果を表示しつつ、カバレッジも取るといったことはすごく簡単にできたが、JenkinsでJUnit形式で出力されたテスト結果ファイルをパースして結果を表示しようと思ったら困ったのでメモ。 mochaの標準のRepoterでは標準出力にしか出力してくれなくて、ファイルに出せなかった。なので npm install xunit-file を追加して、 gulp-mochaのオプションを mocha({repoter: "xunit-file"}) のように指定することで xunit.xml に出力される。 (gulpで標準出力をそのままファイルに落とす方法無いの??) var gulp = require("gulp"), mocha = require("gulp-mocha"), istanbul = require(
前提環境 以下のようなフォルダ構成になっている環境を前提とする。 Windows 7環境で確認。 +node_modules +src | +―ソースファイル.js +test +―テストコード.js Windows上でもmocha+istanbulでコードカバレッジを取りたい。 自分向けのメモ書き。 Node.js + Mocha のUT環境で、コードカバレッジを取りたい!で 検索すると、 npm install mocha istanbul したうえで、 istanbul cover _mocha で出来る、ってのがヒットするが、これはLinux環境の話。 Windows環境での実行方法は以下になる。 npm install mocha istanbul は同様。この状態で、 node node_modules\istanbul\lib\cli.js cover node_module
この記事は CureApp Advent Calendar 23日目の記事です。 今日はフロントエンドのカバレッジの話です。 テストカバレッジとは テストカバレッジとは、テストの際にどれくらいの割合のコードがテストされているか・されていないかを集計した情報のことです。 原理としては、JavaScript の場合は、テスト実行前にスクリプトに変換をかけて、各行に、 その行を実行したことを記録するコード を追加し(この変換のことを Instrumentation と言います)、その状態でテストを走らせます。全テストケース終了後に、各行から出力された行の実行情報を集計してまとめることで、カバレッジレポートを作成しています。 テストカバレッジの意味 テストカバレッジが出せるようになると、行ごとにテストされた・されてないという情報を知ることができ、全体で何%がテストされたという情報をトラッキングする
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く