@ nodefest 2016
この記事は JavaScript Advent Calendar 2015 10日目の記事です。 去年は主に gulp にフォーカスした内容でしたが、今回はJSのビルドとテストにフォーカスした入門記事です。 やること ES2015で書いたコードをWebpackでビルドする babel@6系を使う Mocha + power-assert + jsdom でテストを書く やらないこと gulpまわり React.js CSSビルドまわり 最終的なコードはこちらに上げておきました(すごく簡素な出来です)。 GitHub - sskyu/webpack-power-assert-jsdom-skeleton はじめに 今年はReact.jsがJSerの中で定着した感がありました。 Fluxの考え方を昇華させたReduxがFlux系フレームワークでデファクトになりそうな雰囲気を出しつつ、React
この記事はGoodpatchのエンジニアがお送りするGoodpatch Advent Calendar 2015の1日目の記事です! 1日目は最近Prottチームでおこなったテスト推進施策について書いてみようと思います! 私はProttというプロトタイピングツールの開発を担当しているのですが、Prottには今までサーバーサイドのコードにしか自動テストがありませんでした。 変化のサイクルが速く長期的な運用になる自社サービスは常にコードの形を変えていく必要がありますが、自動テストがないと気軽なリファクタリングをしていくことが難しくなってしまいます。 今回はテスト推進施策ということで、フロントエンド側のテスト環境構築とテストに関連する取り組みを行ったので、その内容をまとめたいと思います。 ポイントは以下の3点です! フロントエンドのテスト環境を作る → Karma + mocha + power
こんにちは。Sales Systemチームの金子です。Sales Systemチームでは、cybozu.com Store や、販売管理システム等の開発をしています。 このエントリでは、cybozu.com 稼働状況のフロントエンドをReact/Reduxで作り直した話を書いていきます。「React/ReduxでWebアプリケーションを作ってみようと考えている人」を対象としています。 TOC 「cybozu.com 稼働状況」とは? 作り直した背景 技術概要 React/Fluxについて React/Redux Routing Resources Async Multilingualization/Localization ES6 Utility Lint Testing 取り組んでみた感想 まとめ 「cybozu.com 稼働状況」とは? クラウドサービスはサービスの稼働状況をステータス
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
今回power-doctestをシンプルなものへと作りなおしました。 rewrite simply by azu · Pull Request #11 · azu/power-doctest 1.0未満のバージョンはツール自体に変換したコードの実行=>レポート表示の機能があったのですが、そこを削除して変換のみを行うように書き換えました。 実行機能はやっぱりとても複雑で、Nodeだけでも結構制御が大変なので、単純にassertに変換して後は他のツールと組み合わせて実行できるような形がいいかなと思いました。 使い方 azu/power-doctest さきほども書いたように変換機能しかないのでライブラリとして使うのがいい気がしますが、単純なファイルを指定して変換するCLIの機能だけは入っています。
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
ライブラリをES6で書いて公開する所から始めよう | Web Scratchで紹介してたazu/espower-babelをアップデートして3.0.0をリリースしました。 espower-babelはBabelの変換 + power-assertの変換を一緒にやってくれるライブラリです。 簡単に言うとES6でテストコードを書いてMochaで動かすのを設定ファイル等を作らないで出来るようにするためのライブラリです。 詳しくは以下の記事を見て下さい ライブラリをES6で書いて公開する所から始めよう | Web Scratch 追記(2016-04-15): espower-babelは非推奨で、.babelrcで直接power-assertを利用するのを推奨しています。 詳しくは次の記事を見てください・ power-assert + babel as a development tool |
使い方 waitForElement(selector, [timeout]) という感じで使います。 waitForElement()はPromiseを返すので、見つかったthenで登録したコールバックが呼ばれて、見つからなかったらcatchが呼ばれるという感じです。 Promiseについて詳しくはJavaScript Promiseの本を見てください /** * Wait until an element that is matched the selector is visible. * @param {string} selector the css selector * @param {number} timeout the timeout is millisecond. default:2000ms * @returns {Promise} */ var waitForElem
改めて覗いてみよう 1) CheckboxWithLabel changes the text after click: AssertionError: # /path/to/test/components/CheckboxWithLabel_test.jsx:21 assert(label.getDOMNode().textContent === 'On') | | | | | | "Off" false | HTMLLabelElement{htmlFor:"",form:null,accessKey:"",control:HTMLInputElement{src:"",valueAsNumber:NaN,incremental:false,defaultChecked:false,form:null,multiple:false,list:null,size:20,checked:f
ユニットテストがしにくい状態となってるコードをTestiumを使ったE2Eテストを書いてリファクタリングしてみる話です。 例えば、以下のようなjQueryで書いたコードは外(テストコード)から取り出すポイントがないので、ユニットテストを書くのは難しいと思います。(そもそもViewのコードなので) 特定のバージョンでの変更点を簡単に確認できるよう、 「Aの列のラジオボタンを選ぶと同じ行より一つ下にあるBの列のラジオボタンを自動で選ぶ」 という補助機能 $(document).ready(function () { // seq: シーケンス番号 $.each(["new_version", "old_version"], function () { $("input[name='" + this + "']").each(function (idx, elem) { if (idx == 0
今までJavaScriptでのユニットテストではexpect.jsを使っていたのだけど、 TDDやライオンで有名なtwadaさんのpower-assertが以前から気になっていて、 つい先日ブラウザ版がIE8に対応したらしく、試しにdeepcopy.jsで使ってみた。 初めての導入で、若干つまづいたところや勘違いしていたところがあったのでメモ。 power-assertについて power-assert自体は単なるアサーションライブラリ。 勘違いしていたのだけどpower-assertのリポジトリのREADME.mdにある、 テストが失敗した時の詳細な出力はpower-assertを使っただけでは表示できない。 espower-cliなどテストコードを変換する必要がある。 node.js node.jsでテストする場合に必要な作業。 モジュールのインストール インストールが必要なモジュール
この記事はECMAScript 2015の事始めとして、ライブラリをECMAScript 2015で書いて公開するというところから始めるのがいいのではという内容です。 ECMAScript 2015(ES2015)はES6とも呼ばれていてどちらも同じものを指しますが、この記事ではES2015に統一します。 ECMAScriptのバージョンについては次のページを参照してください。 ECMAScript · JavaScriptの入門書 #jsprimer 2018-12-27: 追記 textlint/textlint-rule-helperのmasterはTypeScriptの実装へ変換されています。 Babelの実装はhttps://github.com/textlint/textlint-rule-helper/tree/2.0.1から参照できます Babel から TypeScrip
書いた => ライブラリをES6で書いて公開する所から始めよう | Web Scratch ライブラリをES6で書く所から始めよう 目的 6to5の紹介 Node.jsライブラリをES6で書いて公開するのは無理なくて良い 逆にfilesなどnpm公開のベストな手法を選択がセットとなる 現在のES6変換器に求めるべきは構文であって機能じゃない(機能はpolyfillが持つ) letとか変換でどうやっても結果が見えてるので無理に使う必要はないと思う。 Template StingsとかSpread operatorとかCompute property nameとかclassはコード自体がシンプルになるので使っていくといい 今ES6で書く手段 今ES6でコードを書く方法は色々ある。 6to5 Traceur TypeScript Compare · 6to5 ライブラリをES6でnpmで公開して
こんにちは丸山@h13i32maruです。 ES6でアプリコード、テストコードを書いてテストをするための環境を作ったので、そのメモです。 目標 ES6で書いたアプリコードとテストコードをnpm run testでテストする 最終的な環境 最終的にはこんな環境になった。リポジトリ ECMAScript6 Google Chrome Travis CI npm traceur-compiler mocha espower-cli karma karma-cli karma-mocha karma-chrome-launcher bower power-assert 今回はgrunt/gulpのようなビルドシステムは入れていない。npm runをタスク実行のフロントとすることでタスク自体はお手軽にshで書いた。shだとwindowsが厳しいけど、まあとりあえず自分の環境用だしいいかなと。 以降で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く