TypeScript + mocha + power-assert で詰まった話 - Qiita
概要 こちらの記事を参考にしてテスト環境を構築していたのだが、power-assertのいい感じの出力が出てくれなくて悩んだ話 症状 いい感じの出力をしてくれない (tsmochaはmocha --compilers ts:espower-typescript/guess $1/*Test.ts) 原因 テストファイルがtest/**/*.tsに無い場合はうまくいかないぽい。(package.jsonからの相対パス) 解決策 package.jsonにテストディレクトリを明記する たとえば、sample/test以下にテストコードがある時は下のように追加する
karma(+webpack)+babel(es6)+power-assertで動かす - Qiita
// karmaのプリプロセッサー設定(駄目な例) { preprocessors: { "test/**/*.js": ["webpack", "espower"] } } // karmaのwebpack設定(駄目な例) { webpack: { module: { loaders: [ {test: /\.js$/, exclude: /node_modules/, loader: "babel-loader"} ] } } } これでも実行は出来るのですが、2つ問題がありました。 1. karmaのdebugでsourcemapが正しく反映されない 2. karmaのwatchモードが必ず失敗する(:ERROR [karma]: { [Error: no such file or directory]とかのエラー) そのため、都度再起動するのが結構手間でした。 対策 公式リファレン
typescript + karma + mocha + power-assert + browserify メモ - Qiita
なんか選択肢がたくさんあって壮大にハマったのでメモしておきます。 完成形はこれ TL;DR 結論としてbrowserifyでいく場合は karma-browserify + tsify + espowerify でいくのがいいのではと。 karma.conf.jsはこんな感じで書きました。 module.exports = function(config) { config.set({ basePath: '', frameworks: ['mocha', 'browserify'], files: [ 'test/**/*.ts' ], exclude: [ ], preprocessors: { '**/*.ts': ['browserify'] }, browserify: { debug: true, plugin: [ 'tsify' ], transform: ['espowe
TypeScript + mocha + power-assert でプロジェクトルートに tsconfig.json を置いていない時のテスト方法 - Qiita
TypeScript + mocha + power-assert でプロジェクトルートに tsconfig.json を置いていない時のテスト方法TypeScriptmochapower-assertespower-typescript TypeScript で mocha + power-assert + espower-typescript でテストを行う際に、プロジェクトルートディレクトリに tsconfig.json を置かないでテストをする方法が espower-typescript 公式のドキュメントに記載されていなかったので、まとめました。 ディレクトリ構成例 今回、テストを行うディレクトリ構成と説明を以下に示します。 dist テストされる JavaScript が有るディレクトリ test テストする TypeScript が有るディレクトリ。tsconfig.json
JavaScriptのテスト環境構築(Mocha + power-assert + Karma + babel + webpack) - Qiita
JavaScriptのテスト環境構築(Mocha + power-assert + Karma + babel + webpack)JavaScriptmochakarmapower-assert この記事は、初めて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はテスト失敗時に整形されません。 import assert from 'powe
jsdom + power-assert + eater で Invalid TypeError が出て失敗する時 - Qiita
なんかどうも 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
node-v0でassert.deepStrictEqualを使うと`undefined is not a function`になるので - Qiita
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
TypeScript + Angular1系プロジェクトにユニットテストを書く - Qiita
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を動かせるようにする 色々ハマりましたが、最終的にはこちらの記事を参考
karma、mocha、power-assert、webpackで Node.js と Webブラウザ 兼用の TypeScript コードをテストする - Qiita
karma、mocha、power-assert、webpackで Node.js と Webブラウザ 兼用の TypeScript コードをテストするmochakarmapower-assertwebpack 利用ツール群 karma・・・テストランナー。もともとはAngularJSのチームが開発した。 テスト実行の流れを管理する。 テスティングフレームワークを呼び出したり、ブラウザ向けテスト時にブラウザを起動したりする。 mocha・・・テスティングフレームワーク。 BDD や TDD などを可能するフレームワーク。 power-assert・・・アサーションライブラリ。 テストで利用する便利なアサーション群をまとめたライブラリ。 webpack・・・複数のファイルを単一モジュールにまとめる。 参考URL 以下の記事を参考にしました。 TypeScript + power-assert
TypeScript2.1+mocha+power-assertでテストしようとして苦戦した話 - Qiita
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
Node.jsでESLintとMochaとPower-Assertのセットアップ - Qiita
久しぶりにNode.jsに触ってプロジェクトを作ったので共有。 フォルダ構成 bin hoge.js src test mocha.opts .eslintrc index.js package.json mocha.opts --ui bdd --reporter spec --timeout 5000 --require intelli-espower-loader --preserve-symlinks power-assert --preserve-symlinks power-assertが無いとESLintに怒られたので追加した。 node_modules直下に展開されていないと、requireエラーという意味らしい。でも、power-assertのデフォルトでは、symlinkで使えるようになっているので、それを辞める設定かな。 .eslintrc
RSpec で PowerAssert を使うもっとも簡単な方法 - Qiita
RSpec.configure do |config| config.expect_with :test_unit end describe do it do assert { 1 + 2 == 3 * 4 } end end % rspec a.rb F Failures: 1) Failure/Error: assert { 1 + 2 == 3 * 4 } Test::Unit::AssertionFailedError: assert { 1 + 2 == 3 * 4 } | | | | | 12 | false 3 # ./a.rb:7:in `block (2 levels) in <top (required)>' Finished in 0.0131 seconds (files took 0.10485 seconds to load) 1 example, 1 fail
簡単！ JavaScriptで自動UIテスト (NodeJS, Selenium Webdriver, WebdriverIO, mocha, gulp) - Qiita
簡単！ JavaScriptで自動UIテスト (NodeJS, Selenium Webdriver, WebdriverIO, mocha, gulp)JavaScriptNode.jsSeleniummochagulp はじめに Webアプリ開発において、UIのテストは手動になりがちで、 専門のQAチームがいないと、なおざりになるケースが多いかと思います。 本記事では、オープンソースウェアのSelenium Webdriverを主軸に 現時点で筆者が最善だと思う 「JavaScriptで自動UIテストを行う」 方法をご紹介します。(ES6準拠) ポイント ワンライナーで実行可能にする (CI向き) テスト修正が容易 (保守性 高) Windows/Mac環境に依存しない (チーム開発向き) 環境 Windows 10 (Version 1607) / macOS Sierra 10.1
TypeScript + webpack + Karma + Mocha + Power Assertでテストを行う際の諸々の設定ファイル - Qiita
TypeScript + webpack + Karma + Mocha + Power Assertでテストを行う際の諸々の設定ファイルJavaScriptTypeScriptmochakarmawebpack TypeScript + webpack + Karma + Mocha + Power Assertでテストを行う時の諸々の設定ファイル 最近、TypeScriptでコードを書いて、モジュールバンドラにwebpack、テストランナーにkarma、テスティングフレームワークにmocha、アサーションライブラリにPower Assertを使用したユニットテストを書いた その際に、諸々のツールが複雑で、設定ファイルの記述も大変だったので、ここで設定ファイルについてのメモを残しておこうと思う ※現段階では、設定ファイル自体にメモを書いただけです、後で個々の説明を書くかもしれません pa
JavaScriptのテスト環境構築(Mocha + power-assert + Karma + babel + webpack) - Qiita
JavaScriptのテスト環境構築(Mocha + power-assert + Karma + babel + webpack)JavaScriptmochakarmapower-assert この記事は、初めてJavaScriptのテスト環境を作ってみたおじさんによる、これからJavaScriptのテストを書いていきたいけど、登場人物が多すぎてなにやらめんどくさそうと思っている方に向けた記事兼備忘録です。 初めてのJavaScriptテスト環境構築で一応公式ドキュメントに目を通したけど英語の意味をちゃんと読み取れておらず、ツールやライブラリの理解や使い方が間違っている場合がありますのでアドバイスいただけると幸いです。 各テストツールやライブラリの紹介 JavaScriptのテスト環境を構築するときの一つ目の壁がツールやライブラリがたくさん出てきて、どれを使っていいかわからない/それぞ
Reactのテストを mocha + nyc から Jestにしてみる - Qiita
{ "test": "NODE_ENV=test mocha test/", "coverage": "nyc -c npm test" } /srcにソースディレクトリ /testにテストディレクトリ MISC jsdom-global使って色々小細工していた。 mocha -> jestにするモチベーション 興味本位 Jestがv15.0.0でAutomockingを捨てて本気を出してきたのでちょっと使ってみたかった気持ち Railsプロジェクトにjavascriptプロジェクトを混ぜようとしたとき、mochaのテストディレクトリに悩んでしまうぐらいなら、Jestのテストフでやってみようかと思った jestでは、/srcなどのコードに対して、/src/__tests__というディレクトリを作るか、some.test.jsという名前をつけるのがデフォルト設定になっている。 mochaでも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mochaで始めるNode.jsを使ったテスト駆動開発の環境構築 - Qiita
Rails で rspec-power_assert を assert の名前で使う方法 - Qiita
mocha / chai チートシート - Qiita
