mocha で debugger を止める - Qiita
mocha でテストを書いている時に、どうしてもブレークポイントで止めてデバッグしたくなることがあります。 おもむろにコードにdebuggerを仕込みます。 そして mocha コマンドに --debug-brk --inspect とオプションをつけて実行しましょう。 chrome-devtools:// で始まるURLが吐き出されるので、ブラウザでそれを開きます。 $ mocha ./something-spec.js --compilers js:babel-register --debug-brk --inspect Debugger listening on port 9229. Warning: This is an experimental feature and could change at any time. To start debugging, open the f
[めも]mochaとchaiの使い方 - Qiita
ユニットテストって何?って人向けのmochaとchaiの使い方 を見ていて、 MochaとChaiの事が気になったので、簡単な使いかたをメモ。 フォルダ構成 (Nodeが動く環境用) / L package.json L /test package.json (抜粋) "scripts": { "test": "mocha" }, テスト用のコードは、/test 直下に置きます。 (mochaの自動検索対象は、/test直下のみ。) Visual Studio Codeにnpm用の拡張機能を入れておくと、 Ctrl+R Tでテストが実行できるので便利！ (npm run-script test testが呼ばれます。) 参照： Mocha: Getting Started 以上！ ・・で終わってもよいのですが、以下おまけ。 Chaiの使いどころ：assert以外のものも使える Mochaに
![[めも]mochaとchaiの使い方 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/f782b86fd0320aebae9e5784477881ab5d3cd590/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCJUUzJTgyJTgxJUUzJTgyJTgyJTVEbW9jaGElRTMlODElQThjaGFpJUUzJTgxJUFFJUU0JUJEJUJGJUUzJTgxJTg0JUU2JTk2JUI5JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz02NmIwNDdkY2RhMjBiMzVjY2VjZDQ0MzMwMzc3YjYwOA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwdG9yaXMtYmlyZHMmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTFlMzc0YzkzMDdlYzdkNTIyNzU1NDJjY2QzOGE3YmFi%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Ddb5470797cd7ad2d47d34f88cd328ad4)
redux を React などと組み合わせずに入門する - Qiita
はじめに 流行りの redux を React 等、他のフレームワーク/ライブラリと【組み合わせず】に触ってみたので、その記録を残します。 redux という言葉を最近よく聞くけど何なのかは知らない人に、redux がどういうものなのかを知って、使い始めてもらえればもらえれば幸いです。 ついでに、redux はユニットテストに落とし込みやすいと知ったので、mochaとchaiを使ってユニットテストも書いています。 良ければご参考に。 対象 この記事は redux を触ったことがない JS はある程度触ったことがある （必須）webpack, ES6記法 を多分に使っているので、読むことが出来る方 を対象としています。 Redux とは こちらの記事が素晴らしくわかりやすい概念の説明（なんならこれだけでもだいたい理解できちゃう…）が載っているのでぜひご覧ください。 reduxは一言でいうと、
Mocha用のテストファイルでESLintエラー'describe' is not defined no-undef - Qiita
はじめに 長いので、興味のない人は TL;DR まで飛ばしてください。 JavaScriptを綺麗な状態で保つためになくてはならない存在のESLintだが、それが素のJavaScriptではなく、mocha用のテストファイルだと話が変わる。 ファイル内で定義していない関数、describeやitを使うからだ。 そうなってくると、プログラムがエラーだらけになってくる。 しかし、これだけのためにテストファイルに対して、ESLintを無効にするのももったいないので、何か回避する方法が無いのか調べてみてもルール単位、ここではno-undefを無効にする方法しか日本語の解説が見つからなかったので、同じ様な事態になった人の助けになればとこの記事を書く。 TL;DR ソースコードの一行目に
chai-httpでShift-JisのレスポンスをUTF-8に変換する - Qiita
chai.use(chaiHttp); const binaryParser = (res, cb) => { res.setEncoding("binary"); res.data = ""; res.on("data", function (chunk) { res.data += chunk; }); res.on("end", function () { cb(null, new Buffer(res.data, "binary")); }); }; describe('test', function(){ it('API request test', (done) => { chai.request('http://www.example.com') .post('/api/hogehoge') .set('Content-Type', 'application/x-www-fo
JavaScript のテストを書いてみる - Qiita
ちょっとした仕事で、ちゃんとした、 JavaScript のテストコードを書く必要性が生じた。動くテストはかけるが、あまり慣れていない言語で「適切な」テストコードがかけているかは正直わからない。まとまったラーニングコースを受けてみるつもりだが、２ビジネス営業日かかるみたいなので、まず最初に作ってみた。 テストフレームワークをどれを使うかはあたりがついている。Mochaとchai。これは、TypeScriptの頃から同じなので、馴染みがある。そもそもBDD形式のフレームワークなので、使い方はどれも似ている。 Mocha は BDDのテストフレームワークで、chai は, expect などのアサーション部分をBDDフレームワークの形式で書けるようになっている。インストールは次の通り
finallyオペレータを含むObservableのテストを書く - Qiita
// DB操作を伴うとかそういう系のイメージ const Observable = require("rxjs/Rx").Observable; const { map, finalize, catchError } = require("rxjs/operators"); function foo (val) { console.log("foo!"); return val; } // connection closeは常にしたいとか function teardown () { console.log("teardown!"); } // エラーが起きたときだけrollbackしたいだとか function whenError(err) { console.log("some process..."); throw err; } function wantToDo () { retu
【Vue.js】【TDD】ブラウザだけでVueテストを書きましょう - Qiita
基本的に大きなVue.jsアプリケーションを開発するとVue-cliで新しいプロジェクトを作成して、Babel、Jest、Webpackなどを入れます。複雑ですね。でもツールは全部JavaScriptなので、ブラウザだけでも使えます。 この記事で、Node.js、Webpackなどの複雑なツールなしでvue-test-utilsを使ってTDDで簡単なアプリケーションを作ります。ブラウザとスクリプトタグだけで書きます。 何を作る？ これは、MUST-DOアプリケーションです。TODOのようなアプリケーションですが、TODOを入れられないし、削除できないのでMUST-DOです。 ソースコードはここ。index.htmlだけです。 Vueとテストを書くには必要なものは： Vue Vue-test-utils テストランナー （Mocha.jsを使います） 始めます。 検証は？ 簡単なアプリケーシ
Node.jsでのテスト時にローカル関数をstubへのhookする方法 - Qiita
はじめに Node.jsでユニットテストをする場合に、どう設計するのが良いか？を言葉にしてみる。あくまで「私は、これが（今は）しっくりくる」という話。なおASTによるソース解析を含めたHook手法は、今回は行わないものとする。 こちらの記事「テストフレームワークを利用するときの、コード設計について」で書いた「テスト対象の関数から呼ばれる外部関数の全てをフック可能にしておく」と、結論としては同じ。 もう少しスッキリ書けるんじゃないかな？ってのがこの記事の目的。 あと「先にテストを書いてから実装」という話との関連も少し書く。 流れとしては、以下。 こんな風に書くと、テスト時のローカル関数のフックが楽にできる。 この書き方の元にテストを書くとこうなる（実装は無しでテストはFailする）。 実装するとこうなる。 【補足】 2018/07/10：サンプルコードへのリンク（GitHub）を追記しました
TypeScript + mocha + power-assert でプロジェクトルートに tsconfig.json を置いていない時のテスト方法 - Qiita
このコマンドで呼び出される、guess.js の処理はおおむね以下のように処理されています。 カレントディレクトリにある package.json の解析 テストディレクトリなどの設定取得 カレントディレクトリにある tsconfig.json の解析 TypeScript コンパイラオプションなどの設定取得 index.js にカレントディレクトリのパス、TypeScript コンパイラオプションの情報を渡し実行 テストを実行する際はほぼプロジェクトルートディレクトリで行われると思うので、カレントディレクトリはプロジェクトルートディレクトリに読み替えることが出来ます。 この時、手順 2においてプロジェクトルートディレクトリに tsconfig.json が存在しないため null が返ってきてしまいコンパイラオプションを取得できず、テスト実行に失敗してしまいます。 ローダの設定とテストの
mochaのhook関数が呼ばれる順番 - Qiita
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のテスト環境構築(Mocha + power-assert + Karma + babel + webpack) - Qiita
この記事は、初めてJavaScriptのテスト環境を作ってみたおじさんによる、これからJavaScriptのテストを書いていきたいけど、登場人物が多すぎてなにやらめんどくさそうと思っている方に向けた記事兼備忘録です。 初めてのJavaScriptテスト環境構築で一応公式ドキュメントに目を通したけど英語の意味をちゃんと読み取れておらず、ツールやライブラリの理解や使い方が間違っている場合がありますのでアドバイスいただけると幸いです。 各テストツールやライブラリの紹介 JavaScriptのテスト環境を構築するときの一つ目の壁がツールやライブラリがたくさん出てきて、どれを使っていいかわからない/それぞれの役割がわからないことだと思う。 なので、まずはJavaScriptのテスト環境についてググったときに出てくる最近使われてそうな各ツールやライブラリの役割をすごく雑に紹介します。 テストフレームワ
power-assertの例外処理を見やすくする - Qiita
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はテスト失敗時に整形されません。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ESLint&mochaで’describe’ is not definedと言われないために - Qiita
Javascriptでselenium-webdriverを使ったテスト(メモ) - Qiita
TypeScript + mocha + power-assert で詰まった話 - Qiita
karma(+webpack)+babel(es6)+power-assertで動かす - Qiita
Sinon.JSチートシート、を目指したメモ - Qiita
typescript + karma + mocha + power-assert + browserify メモ - Qiita
mochaによるテスト、mongodb初期化 - Qiita
