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はテスト失敗時に整形されません。
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を動かせるようにする 色々ハマりましたが、最終的にはこちらの記事を参考
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
Windows環境でProtractor動かしてみる - Qiita
nodeを入れる 入っている方は読み飛ばしてください。 nodeのバージョン管理ソフト「nodist」を入れる 公式サイトからインストーラを取得する。 https://github.com/marcelklehr/nodist#installing-with-the-official-installer 特に問題がなければデフォルトのままインストールする。 参考： http://qiita.com/yokoh9/items/20d6bdc6030a3a861189 Gitクライアントを入れる Gitクライアントにパス通っていれば良い。 無ければ入れる。 Git GUIを入れる。 ここからインストーラを取得する。 http://git-scm.com/download/win 設定を二か所、デフォルトから変更する。 cmd.exe以外からも使うように設定変更する。 checkoutとcomm
protractorでAzure AD ログインしてみる - Qiita
protractor 実行下でAzure AD（以下、AAD）にログインしてみた。 ※AADログイン画面へのURL生成手順等は割愛。 自アプリから画面遷移してAADでログインする際、 browser.driver.sleepを使用してProtractorのコード実行タイミングを調整。 'use strict'; describe('My App', function() { // 認証情報 var EMAIL = "test@test.onmicrosoft.com"; var PASSWORD = "Abc1234567"; // AngularJSを使用していないページでのテストを許可 browser.ignoreSynchronization = true; // AADログイン画面へのURLなどを指定、遷移するページ var LOGIN_URL = "http://localhos
ProtractorとAngularJSではじめてのE2Eテスト - Qiita
この記事は前回からの続きとなります。 AngularJSのE2Eテストといえば、Protractorですね。公式ページにもあるfor AngularJSの記述がなんとも心強いです。 ProtractorはAngularJSのために開発されているだけあり、テスト実行時に何も考えずとも__AngularJSと同期してくれる__という最強に素晴らしい機能を備えています。 何を同期してくれるのか AngularJSはモデルの変更を検知するためにScope Life Cycleという機構を備えています。この機構によりモデルの変更は即座に検知され、同時にビューを最新の状態に保ちます。Protractorはこのライフサイクル中に実行される$digestループの完了を検知（同期）してくれるので、ビューの再レンダリングが完了する前にテスト処理が実行されてしまうといった事態を確実に回避してくれます。 また、$
gulpでProtractor(Selenium+Jasmine)を動かす - Qiita
ProtractorはAngularJSのためのE2E(End To End)テストのフレームワークです。 AngularJSのための、といっても中身はSelenium(ブラウザの自動操作ツール)とJasmine(javascript用のテストフレームワーク)なので、普通にWebシステムのE2Eテストとして使うことができます。 今回は、Protractorのインストールからgulpで実行するまでについてまとめます。 インストール npm(node.js)とgulpは入っている前提で。 Protractorはnpmからインストールし、webdriver-managerのupdateを実行します。 npm install protractor node node_modules/protractor/bin/webdriver-manager update Protractor単体で動かす S
ProtractorのテストコードをTypeScriptで書く - Qiita
前の記事でProtractorの導入を行いました。 しかし、JavaScriptでそのまま書いていたので、できればTypeScriptで書きたい。 さらにその上で、webpackを使って複数のテストコードをbundle化し、一つのjsファイルにします。 準備 今回使うパッケージを一通り入れておきます。 前回入れたprotractor関連は書いてないので、そちらは前の記事を参考にしてください。 typescript webpack ts-loader gulp gulp-typescript gulp-webpack glob npm install typescript webpack ts-loader gulp gulp-typescript gulp-webpack glob TypeScriptでコードを書く 今回もProtractorのデモサイトを使ったテストコードを書きます。
フロントエンドのテストに真面目に向き合う - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最新版=>フロントエンドのテストについて考える 背景 フロントエンドのテストは、テストランナー、フレームワーク、Node.js、ブラウザ、Selenium、WebDriverなど、登場人物が多い。また、UIと密接に絡むのも特徴である。 これまで社内では、テスト種別によって、それぞれ解決したい事柄が明示的に示されていなかった。それぞれのテスト種別にどんな意味があり、何を目的とするかを明確にすることで、機能に対して、どのようなテストを実装すればよいのか共通認識を持っておくために、この記事を作成した。 フロントエンドのテスト4象限 今回この記
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
karma、mocha、power-assert、webpackで Node.js と Webブラウザ 兼用の TypeScript コードをテストする - Qiita
Node.jsでESLintとMochaとPower-Assertのセットアップ - Qiita
mochaで始めるNode.jsを使ったテスト駆動開発の環境構築 - Qiita
RSpec で PowerAssert を使うもっとも簡単な方法 - Qiita
Rails で rspec-power_assert を assert の名前で使う方法 - Qiita
iPhone SimulatorでJavaScriptの自動テストを動かす - Qiita
