blanketでmochaで書いたテストのカバレッジを測定する

mochaで書いたテストのカバレッジ(網羅率)を取るにはどうしたらよいのかと思っていたところ、blanketというのを見つけたので試してみました。

早速、blanketとmochaでテストを走らせた際にカバレッジを表示させられる様にするためのレポーターを追加します。

$ npm install --save-dev blanket
$ npm install --save-dev mocha-spec-cov-alt

blanketの設定をpackage.jsonに追記します。data-cover-neverにはカバレッジ測定の対象としないディレクトリを明記します。ここではテストが入っているディレクトリとnpmのパッケージがインストールされているディレクトリを除外しています。

  "config": {
"blanket": {
"pattern": [
""
],
"data-cover-never": [
"node_modules",
"test"
]
}
}

更に npm test を実行する際の設定を以下の様に修正します。mochaを呼び出す際に以下の2つのオプションを追加します。

  • レポーターにmocha-spec-cov-altを指定 -R mocha-spec-cov-alt
  • 実行時にblanketを読み込む様に指定 --require blanket

修正例としては以下の様な形。

  "scripts": {
"test": "NODE_ENV=\"testing\" mocha -R mocha-spec-cov-alt --recursive --require blanket "
},

ここまででテストのカバレッジがmochaの実行結果として表示される様になります。*1

npm test を実行すると

f:id:hideack:20150801114446p:plain

といった形でテストの末尾にカバレッジが表示される様になります。

参考

blanketjs.org

github.com

*1:コメントに従ってscripts修正しました

Google docsのスプレッドシート上に記載されたURLのいいね数を取得する

Google docsネタ第2弾 エントリ。

仕事でGoogle docsにメモられたURLにつけられたfacebookのいいね数をとりたいなと思ったので、以下の様なスクリプトgoogle docsで作成して解決。

スプレッドシートの「ツールスクリプトエディタ」で空のプロジェクトを使って以下の様なスクリプトを書きます。

function fb(uri) {
var cache = CacheService.getPublicCache();
var cacheKey = "fb:like:" + uri;
var likeNum;
likeNum = cache.get(cacheKey);
if (likeNum == null) {
var apiUrl = "http://api.facebook.com/method/fql.query?format=json&query=select+total_count+from+link_stat+where+url%3D%22";
apiUrl += uri;
apiUrl += "%22";
var responseJson = UrlFetchApp.fetch(apiUrl);
var items = Utilities.jsonParse(responseJson.getContentText());
likeNum = items[0].total_count;
if (isFinite(likeNum)) {
cache.put(cacheKey, likeNum, 60 * 60 * 8);
}
}
return likeNum;
}

味噌は使っているのがGoogle docsということで、同じ社内のネットワークから複数の人が同時にスプレッドシートを開いて閲覧することは当然あるわけでそうするとそのたびにfacebookAPIを叩くことになってAPIのレスポンスを得られなくなるので CacheService を使ってキャッシュさせているところですね。

とセルに書いてあげることで、いいね数が返ってくる様になります。

とても便利なのでぜひお試しを。

dockerでWordPressを動かしてみる

同様のエントリは多々公開されていますが、自分のメモとして...。

WordPressを運用しているとそのテンプレートを修正したりという機会も多くなって手元で動かしたいと思うことも多いのでローカルの開発環境を作りたいと思ってboot2dockerを利用してdockerでWordPressを動かすことをやってみました。

boot2docker

https://github.com/boot2docker/osx-installer/releasesインストーラーあるのでこれ入れるだけ

github.com

boot2dockerの設定

☁  ~  boot2docker init
Latest release for github.com/boot2docker/boot2docker is v1.7.1
Downloading boot2docker ISO image...
Success: downloaded https://github.com/boot2docker/boot2docker/releases/download/v1.7.1/boot2docker.iso
to /Users/hideack/.boot2docker/boot2docker.iso
Generating public/private rsa key pair.
Your identification has been saved in /Users/hideack/.ssh/id_boot2docker.
Your public key has been saved in /Users/hideack/.ssh/id_boot2docker.pub.
The key fingerprint is:
59:11:75:cb:a6:11:bd:ba:46:d9:73:fe:42:90:d5:5f hideack@mac.local
The key's randomart image is:
+--[ RSA 2048]----+
|          ooo... |
|           . +o.E|
|          . .o+.o|
|         o  o+. .|
|        S   .=   |
|            + + .|
|           . o + |
|            o . .|
|           .   .o|
+-----------------+
Initialization of virtual machine "boot2docker-vm" complete.
Use `boot2docker up` to start it.

boot2docker起動

☁  ~  boot2docker start
Waiting for VM and Docker daemon to start...
........................oooooooooooooooooo
Started.
Writing /Users/hideack/.boot2docker/certs/boot2docker-vm/ca.pem
Writing /Users/hideack/.boot2docker/certs/boot2docker-vm/cert.pem
Writing /Users/hideack/.boot2docker/certs/boot2docker-vm/key.pem
To connect the Docker client to the Docker daemon, please set:
export DOCKER_TLS_VERIFY=1
export DOCKER_HOST=tcp://192.168.59.103:2376
export DOCKER_CERT_PATH=/Users/hideack/.boot2docker/certs/boot2docker-vm
Or run: `eval "$(boot2docker shellinit)"`

dockerの環境変数を設定してねと書かれているのでそれにしたがって ~/.bashrc なり ~/.zshrc に追記

### Docker
export DOCKER_TLS_VERIFY=1
export DOCKER_HOST=tcp://192.168.59.103:2376
export DOCKER_CERT_PATH=/Users/hideack/.boot2docker/certs/boot2docker-vm

WordPressイメージをダウンロード&起動

続きまして、WordPressのイメージをダウンロードします。

☁  ~  docker pull tutum/wordpress
latest: Pulling from tutum/wordpress
e9e06b06e14c: Pull complete
a82efea989f9: Pull complete
(snip)
047ca869fcbc: Pull complete
6e56521c4625: Pull complete
acac8eca5408: Pull complete
5025a6da41dd: Already exists
Digest: sha256:fdea02dff482eb7df1c206cc2ffc7fafb3a0844b89c91815d2495398af4cb128
Status: Downloaded newer image for tutum/wordpress:latest

ここで満を持してコンテナを起動します。

☁  ~  docker run -d -p 80:80 --name=wordpress tutum/wordpress
4f37784d6f44c754d4f1aa54ed803ec6190396ae9e509d6b3a5e74bd9782464c

起動できているか docker ps コマンドで確認するとWordPressのコンテナのプロセスが起動していることが確認できます。併せてブラウザで確認するための接続先を boot2docker ip で確認。

☁  ~  docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                          NAMES
4f37784d6f44        tutum/wordpress     "/run.sh"           7 seconds ago       Up 7 seconds        3306/tcp, 0.0.0.0:80->80/tcp   wordpress
☁  ~  boot2docker ip
192.168.59.103

ブラウザで http://192.168.59.103 を開くと....

f:id:hideack:20150720100535p:plain

無事起動しました。実際にテンプレートのデザインを開発するときはもう一声対応が要りそうなのですが、そちらはまた追って。

npm-check-updates でpackage.jsonに記載されたnode moduleの更新状況を確認する

タイトル長い。

Node.jsではアプリケーションで利用するnpmモジュールを package.json に定義しておく訳ですが、こちらで定義されたそれぞれのモジュールのアップデート状況を確認したり併せてpackage.jsonを更新する方法が知りたかったのでその際調べたメモ。

npmコマンドで npm outdated とすることでpackakge.jsonに定義された各パッケージの現在インストールされているバージョン、package.jsonで定義されているバージョン、npmで管理されている最新のバージョンを列挙することはできるのだけど、実際に手元にあるpackage.jsonの更新までは行ってくれません。

そこでnpm-check-updatesを利用します。

まず、npm-check-updatesをインストール

$ npm install -g npm-check-updates

そうするとコマンドとして npm-check-updates がインストールされるのでpackage.jsonが置かれているパスで実行します。

$ npm-check-updates
"compression" can be updated from ^1.5.0 to ^1.5.1 (Installed: 1.5.0, Latest: 1.5.1)
"errorhandler" can be updated from ^1.4.0 to ^1.4.1 (Installed: 1.4.0, Latest: 1.4.1)
"loopback" can be updated from ^2.18.0 to ^2.19.0 (Installed: 2.18.0, Latest: 2.19.0)
"loopback-datasource-juggler" can be updated from ^2.32.0 to ^2.33.1 (Installed: 2.32.0, Latest: 2.33.1)
"youtube-api" can be updated from ^1.0.0 to ^1.0.1 (Installed: 1.0.0, Latest: 1.0.1)

更新可能なパッケージが確認できますね。

この更新を package.json に反映させたい場合は、 -u オプションを付けて実行します。

$ npm-check-updates -u

これでpackage.jsonが更新されるので実際に、 node_modules の中身を更新します。

$ npm update
compression@1.5.1 node_modules/compression
├── bytes@2.1.0
├── on-headers@1.0.0
(snip)
└── strong-remoting@2.20.0 (eventemitter2@0.4.14, qs@2.4.2, js2xmlparser@0.1.9, traverse@0.6.6, sse@0.0.6, request@2.58.0, mux-demux@3.7.9, jayson@1.2.0, xml2js@0.4.9)

これでpackage.jsonで定義されている全てのnode moduleを更新することができました。

2015年6月に読んだ本を振り返る

6月は10作品。完全に自分の興味が赴くままにそしてエンジニアリング以外の部分での仕事のヒントを求めてひたすら読んでいる感じであった。まだ足りないのであと数倍インプットしなければと思っている。

単純に興味で読んだ 土俵の矛盾 - 大相撲 混沌の中の真実 も現在まで行われている「大相撲」というものをどの様に捉えるとよいのか。客観的に現場に居た著者が歴史とともに紐解きながら提言を重ねていく内容がとても興味深かったので、相撲好きの方にお勧め。


hideackの本棚 - 2015年06月 (10作品)
正直
松浦弥太郎
読了日:06月20日



文具上手
土橋正
読了日:06月28日


powered by booklog

Google docsのスプレッドシートで集計する際にSQLっぽいクエリを使う

最近業務でgoogle docsExcelで管理されたシートの内容を集計したいことがあって、基本google docsスプレッドシートでゴニョゴニョすることがあるのですが、例えば

の様なものがあって、上の例だと各ユーザのポイントの合計を集計したいなと考えた時にExcelに慣れている方だとExcelの関数が浮かんで集計できるのかと思うのですが自分だとSQL文のイメージが先に出るのでよしなにできないかなと思っていたら、Google docsだと QUERY という関数を使うことで実現できることを知ったのでメモエントリです。

上の例だと D1 のセルに以下の様な内容を記述します。

=query(A2:B9, "select A, sum(B) group by A")

1番目の引数にデータの範囲を指定し、2番目にそのデータ範囲でのクエリを記述します。

SQLを触ったことがある方ならなんとなくわかる記述内容かと思います。入力を完了するとすぐにセルに集計結果が反映されます。

なるほどとても便利。Google docs初期からの機能だった様なのですが本格的に最近触る様になったのでやっと便利さに気づけました。

参照

Query Language Reference (Version 0.7)   |   Charts   |   Google Developers

loopback-testingを利用してloopbackで作成したAPIのテストを書く

loopbackでAPIのテストを書く際にloopback-testingを利用してAPIのテストを書いてみたのでその際のメモ。

まずは必要なnpmパッケージをloopbackアプリケーションに導入します。loopbackアプリのルートで以下のnpmコマンドを実行。

www.npmjs.com

$ npm install loopback-testing --save-dev
$ npm install chai --save-dev

これで準備完了。加えて npm test でテストを実行できる様に package.json 内のscriptsの定義を以下の様に書き換えます。*1

"scripts": {
"test": "NODE_ENV=\"testing\" ./node_modules/loopback-testing/node_modules/.bin/mocha -R spec --recursive"
}

上記の意図は npm test が実行された際に testing 環境としてnode_modules配下のmochaを利用してテストを実行します。

それにともなってtesting環境でloopbackアプリが実行された際のデータソース(DB接続先)を定義しておきます。Circle CI等のCI環境でもすぐに実行できる様に、memoryを指定します。

~/server/datasources.testing.js というファイルを用意して以下の様にデータの保存先をmemoryに指定します。

module.exports = {
db: {
connector: "memory",
defaultForType: "db"
}
};

これでテストが実行できる様になりました。expressの流儀と同様にプロジェクト直下の test ディレクトリに現在開発しているloopbackアプリケーション(API)のテストを書いてみます。

例えばユーザ登録(メールアドレスとPWをPOSTするとユーザ登録できる)のAPIのテストであれば、

var lt = require('loopback-testing');
var chai = require('chai');
var assert = chai.assert;
var app = require('../../server/server.js');
describe('/api/users', function() {
var newUser = {email: "tester1@remp.jp", password:"tester1remp"};
describe('ユーザ登録', function() {
lt.describe.whenCalledRemotely('POST', '/api/users', {}, function() {
it('ユーザ登録の際にメールアドレス、パスワードのパラメータは必須', function() {
var codes = this.res.body.error.details.codes;
assert.include(codes.password, 'presence');
assert.include(codes.email, 'presence');
assert.include(codes.email, 'format.null');
});
});
lt.describe.whenCalledRemotely('POST', '/api/users', newUser, function() {
it('メールアドレス, パスワードを与えるとユーザ作成できる', function() {
assert.equal(this.res.statusCode, 200);
});
});
});
});

といった具合に記述することができます。

ほぼコードを読んだままなのですが、 lt.describe.whenCalledRemotely の記述で指定のエントリポイント下へ指定のメソッド及びパラメータでアクセスがあった場合のテストを書くことができます。

また、アクセスするユーザにロールや状態をもたせた状態のテストも同様に記述ができ、例えばログインを行ったユーザによるAPIへのアクセスを想定したテストは

  var user = {
id: 2,
email: "tester2@remp.jp",
username: "tester2",
password: "tester2remp"
};
// (snip)
describe('ユーザによるプレイリスト操作', function() {
lt.describe.whenCalledRemotely('GET', '/api/users/2/playlists', function() {
it('未ログインユーザはユーザのプレイリストは取得できない', function() {
assert.equal(this.res.statusCode, 401);
});
});
lt.describe.whenCalledByUser(user, 'GET', '/api/users/2/playlists', function() {
it('ログインしたユーザ自身のプレイリストは取得できる', function() {
assert.equal(this.res.statusCode, 200);
});
});
});

の様に lt.describe.whenCalledByUser という記述で実現することができます。他にも各種ロールを割り当てた上での記述が行える様になっています。

こういった形でテストを用意した上で npm test で実行してみると...

といった具合にmochaによるテストが実行できています。

loopbackで作成したAPIであれば、loopback-testingを用いることでアクセスするユーザの各種ロールを想定したテストが記述できて便利ですというお話でした。

まとめ

  • loopbackアプリケーションでのテストを行うために loopback-testing を導入しました
  • npm test でテストを実行できる様にpackage.jsonの一部を修正しました
  • whenCalledRemotely, whenCalledByUser 等 loopback-testingを利用することで用意に各種ロールを想定したテストが書けました

あわせて読みたい

*1:loopbackのscafold(slcコマンド)で作成された場合は仮のpretestの定義が書いてあります

githubで管理されているnpmパッケージをnpmコマンドでインストールする

メモエントリ。

npmパッケージを npmjs.com で管理されているものではなくgithub上に管理されているものを直接npmコマンドでインストールする方法。
例えば、evacの場合、

$ npm install hideack/evac

とすることで、github上のmasterから直接インストールすることができる。npmコマンド奥が深い。

併せて読みたい

hideack.hatenablog.com

2015年5月に読んだ本を振り返る

技術書が無いぞ技術書が。

とはいえ、いろいろ思うところが現れている読書ログ。

家庭用ゲーム機興亡史 はとても面白かった。各時期における家庭用ゲーム機メーカーのとった商品戦略や営業戦略によってここまで市場が変化するのかというのがわかる。また10年後ぐらいに更にこの本に記載された内容からどの様な追記がされるかとても興味がある。

果たしてそのとき所謂家庭用ゲーム機は残っているのだろうか。

ナマコ は相変わらずの椎名誠の世界でどーだどーだ的に面白く、ビールをぐいぐいと呑みたくなるのだ。


hideackの本棚 - 2015年05月 (8作品)


ナマコ
椎名誠
読了日:05月31日


powered by booklog