testem + mocha + istanbul で網羅性の高いテスト駆動開発 - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
WebStormでNode.jsアプリをデバッグする(Mocha, Typescript版もあり) - Qiita
WebStormだと様々な形式のNode.jsアプリが簡単にデバッグできます． 実際に画像で見てみましょう 単純なNode.jsアプリの場合 1. Javascriptを書いてブレークポイントを置く 2. 右クリック＞Debug app.js 3. やったぜ Mochaのテストをデバッグしたい場合 1. mochaを入れる 上メニューFile>Settings > Node.js and NPM > 緑の＋ボタン > mochaをInstall Package 2. mochaのテストを書いてブレークポイントを置く testというフォルダを作ってその中にテストJS 3. 上メニューRun>Edit Configurations 4. 左上の＋ボタン＞Mocha 5. Mochaの設定をしてOKで閉じる ほとんどの項目は初期のままでよい． 以下の項目は自分で指定する必要があるかも 項目名 意
grunt+istanbul+mochaでNode.jsのテスト＆カバレッジ計測を行う - Qiita
単体テストの件数や可否ももちろんですが、コードのカバー率も可視化されることで、品質向上の1つの指標にもなります。 Node.jsで開発しているプロジェクトについて、こういったデータをgruntタスクで簡単に生成できるようにしましょう。 仕組みとして使うものは以下のとおりです。 grunt: JSタスクランナー mocha: JSテストフレームワーク chai: BDD/TDDアサーションライブラリ sinon: Spy,Stub,Mockライブラリ istanbul: コードカバレッジ計測ツール gruntは既に導入済みで、活用している前提とします。 JSのテストはJasmineが有名ですが、自由度の高いmocha+chai+sinonが個人的にはお気に入りなのでこちらを使います。 コードカバレッジ計測はいくつかの選択肢がありますが、メソッドや行、分岐等を計測できるistanbulを使いま
gulp + webpack + mocha + assertでブラウザとコンソール両方でテストするサンプル - Qiita
var gulp = require('gulp'); var gutil = require('gulp-util'); var webpack = require('webpack'); var WebpackDevServer = require('webpack-dev-server'); var webpackConfig = require('./webpack.config.js'); var open = require('gulp-open'); var mocha = require('gulp-mocha'); // default task is browser test gulp.task('default', ['browser-test']); // browser test gulp.task('browser-test', function (callba
TypeScript & CoffeeScript & Browserify & mocha & Reactによるフロントエンド開発環境 - Qiita
このプロジェクトは以前のプロジェクトにmochaとReactの対応、自動ビルド時間短縮を施した置き換え版です。 GitHubへのリンク 概要 このプロジェクトは、AltJS(TypeScript & CoffeeScript) & Browserify & mocha & React構成の雛形プロジェクトです、以下の機能を持っています。 TypeScript、Browserifyの差分ビルド gulp.watch、Watchifyの変更監視による自動ビルド TypeScript、CoffeeScriptのソースファイルを混在出来る ファイルごとに型が欲しいか、短く書きたいか、で好きな方を選べばいい CoffeeScriptで書いたクラスをTypeScriptでrequireして使う、等 ※当然ですが、型チェックをするならTypeScript同士じゃないとダメ mochaによるテスト また、
Mochaを使うときはassert.strictEqualを使ったほうがいいな?という話 - Qiita
var assert = require('assert'); it('test1 strictEqual', function() { var a = 'abcde'; var b = 'abcdf'; assert.strictEqual(a, b); }); it('test1 eqeqeq', function() { var a = 'abcde'; var b = 'abcdf'; assert(a === b); }); it('test2', function() { var a = { hoge: 12 }; var b = { hoge: 13, fuga: 56 }; assert.deepEqual(a, b); }); 1) test1 strictEqual 2) test1 eqeqeq 3) test2 0 passing (15ms) 3 failing
Xcode Application Unit Testセットアップ - Qiita
Logic Unit Testは、Testターゲットを作成するだけで実行できるが、肝心のアプリコードをテストするためのSenTestingKitでのApplication Unit Testはそのままでは動かなかったのでメモ いろいろUnit testターゲットのCompile Sourcesにアプリのソースファイルを入れてみたり試行錯誤してみましたがうまくいきませんでした。 で、Xcode Unit Testing Guideを見たらに普通に書いてあったので、それによると、 Unit testターゲットのプロジェクトエディタで、Build Settingsのタブを開く Build SettingsをAllに切り替え LinkingのBundle Loaderの値を設定:app_nameは特別なことをしてなければプロジェクト名 $(BUILT_PRODUCTS_DIR)/app_name.
AndroidのカバレッジをEmmaで継続的に確認してUnit Testを出来るだけ書いてみる俺プロジェクト - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 始めに 以前にも少しメモで書いたりしたが、Androidのアプリ開発でEclipseを使っている場合にAndroid標準のAndroid Test Projectを使っているとカバレッジを確認できない。個人的には、これがかなりUnit Testへのモチベーションを下げているのではないかと考えた。 よろしくない話ではあるが、実際現場のプロダクトでAndroid Test Projectを作成しようとしたときに、どこまでUnit Testを書き込むか悩む場面が多かった。 そして、結局時間を言い訳に、ろくにUnit Testは行なわず、、、と
gae/g unit testing - Qiita
golangにはgo testというunit test用の機能があります。 testを行うための [testing] (http://golang.org/pkg/testing/) package もあります。 しかし、gae/gでは、appengine固有の部分が動かないため利用できませんでした。 そこを解決するために以下のlibraryなどもあったのだけど、 gae 1.8.6でついにgae/gでもunit testができるようになりました！ [Local Unit Testing for Go] (https://developers.google.com/appengine/docs/go/tools/localunittesting) gae/g unit testで重要なのは、以下の3つです。 goapp test appengine/aetest testing この3つを
ScalaとAndroidとUnitテスト - Qiita
前回はとりあえずScalaでAndroid開発が出来そう！ってところで終わりました。 でも開発するにはあれですよね、(Developer)Testがやりやすいというのも重要ですよね ってことでとりあえずやってみた結果がこちら Android特有のテストに関して src下の instrumentTest に配置することで、sbt android:testで動かせます Ant Styleの場合はsrcと並列に tests ディレクトリを作成して同様にやればOKです フツーならtest側にもAndroidManifest.xmlが必要ですが、android-sdk-pluginが適当に補完してくれるので特に配置する必要は無いです もちろん配置してもOKです android:debug-includes-tests を false にすると自分でどうにかしないとダメなのかな？ これでscalaでめ
Test::Unitのassert一覧 - Qiita
assert assert_block assert_equal assert_no_match assert_not_equal assert_not_nil assert_not_same assert_not_send assert_nothing_raised assert_nothing_thrown assert_raise assert_raise_with_message assert_respond_to assert_send assert_throw assert(test, [failure_message]) assert_block( failure_message = nil ) assert_equal( expected, actual, failure_message = nil ) assert_no_match( regexp, string, fa
App ExtensionsのUnit testing - Qiita
App Extensionsのテストコードを書きたいなと思って、いざやってみると少し苦労した話です。 2014/12/17 potatotips #12で発表した内容です。 発表資料はこちらです。 前置きとして簡単にApp Extensionsとユニットテストの説明を記載しましたが、既にご存知の方は飛ばしてください。 App Extensionsとは iOS 8.0とOS X v10.10以降、App Extensionsにより、アプリケーションを超えて独自の機能と コンテンツを拡張でき、ユーザが他のアプリケーションやシステムを利用している場合でも、それ らを利用することができます。 提供されているExtension Extension point Typical app extension functionality
Android Studio で Unit Test - Qiita
alt + enterで、 Create Testメニューを実行すると、 このようなダイアログが表示されまして、 必要に応じて、setUp/tearDownにチェックを入れます。 またすでに実装されているメソッドの一覧が表示され、 チェックを入れると、自動的にtest用メソッドが追加されます。 OKを押し進めると、 Test用クラスが生成されます。 Test実行 メニューの Run → Edit Configurations.. から +ボタンを押し、 Android Tests を選択 初期状態は、 Module が no moduleになっているので、 所定のものを指定。(今回でしたら、app) Testを実行したい場合は、 ツールバーにて先ほど作成して、Android Testsを指定し、 実行。 結果 仮にSampleTestに以下のようなコードを書いた場合 public void
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WebStormでKarma+Mocha+power-assertのjavascriptテスト環境を作る - Qiita
Konachaの導入手順とheadlessテストで出力フォーマットを変更する方法 - Qiita
@mochaのマイページ - Qiita
mocha-phantomjsでテスト - Qiita
Test::Unitで実行中のテストケースを表示する - Qiita
Coffee-script+mochaコンパイルせずにテスト - Qiita
# jenkinsでのunitテストは、dockerでクリーン環境を作って行おう - Qiita
