Posts tagged: テスト

socket.io-clientを用いてExpress+Socket.IOで作ったサービスへ同時接続テストを行う

このエントリーをはてなブックマークに追加
はてなブックマーク - socket.io-clientを用いてExpress+Socket.IOで作ったサービスへ同時接続テストを行う

Express3.x(connect2.3+)とSocket.IOでのセッション管理mochaとsuperagentでexpressを使ったサービスのログイン周りのテストの続き。

今回はsocket.ioの同時接続のテストについて。今回は

  • 1000人同時接続が出来るか
  • 正しくメッセージのやりとりが出来るか(チャットなので)
  • ログイン済みユーザーのみが接続できるか
のテストを行なってみました。

socket.io-clientを用いれば、コンソールから同時接続のテストが簡単に出来ます。
ただし、環境によってはOS自体のファイルディスクリプタの最大数を引き上げないと1000人同時接続は難しいです。


ソースコード

今回は今までのを全て含めたものをgithubに上げています。
pxsta / express-socket.io-chat-test


今回の環境

  • Mac OSX 10.7.4 Lion
  • socket.io@0.9.10
  • socket.io-client@0.9.10
  • express@3.0.0rc3


やったこと

ファイルディスクリプタの最大数の変更(環境によっては不要)

1000人同時接続のテストを行う際にはOS自体のファイルディスクリプタの最大数を引き上げる必要があります。
少なくともMacでは256などというとても低い値に設定されているのでそのままでは無理です。

Mac OSX 10.7.4 Lionの環境で1000人接続のテストを行った所、117人あたりで接続を受け付けなくなるか、以下のようなエラーで止まってしまいまいした。
[ERROR] console - Error: EBADF, Bad file descriptor
/node_modules/express/node_modules/connect/lib/middleware/errorHandler.js:68
                .replace('{style}', style)
                 ^
TypeError: Cannot call method 'replace' of undefined
    at /node_modules/express/node_modules/connect/lib/middleware/errorHandler.js:68:18
    at [object Object]. (fs.js:80:5)
    at [object Object].emit (events.js:64:17)
    at fs.js:820:12

Macの場合は
$ ulimit -n
256
$ sysctl kern.maxfilesperproc
kern.maxfilesperproc: 10240
$ ulimit -n  10240
$ ulimit -n  
10240
のようにして変更可能です。ulimitにkern.maxfilesperprocの値を設定すれば最大値まで引き上げられます。


socket.io-clientによる同時接続のテスト(1000人くらい)

socket.io-clientを用いれば同時接続のテストをコンソールから行うことが出来ます。
以下のように、接続自体は今までクライアント側で書いていたものをサーバ側でそのまま使うことが出来ます。
var io = require('socket.io-client');
var options = {
    'force new connection' : true,  //別々のコネクションとして認識させるために必要
    port : 3000
};

//接続
var socket = io.connect("",options);
socket.on('connect', function(data) {
    done("wrong behaviour");
});

//メッセージの送信
socket.emit("chat","send message test");

そのため、複数人接続のテストはmochaと組み合わせて以下のようにして簡単に出来ます。
var should = require('should')
  , expect = require('expect.js');
var options = {
    'force new connection' : true,  //別々のコネクションとして認識させるために必要
    port : 3000,
};

//socket.ioの接続テスト
describe('socket.io test', function() {
    it('1000件接続出来るかどうか。ファイルディスクリプタの最大値を大きくしないと一度に接続できない', function(done) {
        this.timeout(600000);
        var maxCount = 100;
        var clientCount = 0;
        var clients = [];
        
        //全てが接続し終わったら全て切断してから終了
        var end = function() {
            for (var k=0;k<clients.length;k++) {
                clients[k].disconnect();
            }
            done();
        }; 
        
        //maxCount個のクライアントを接続する
        for (var i = 0; i < maxCount; i++) {
            var client = helper.login({
                auth : {
                    userID : 'test' + i,
                    password : 'test'
                },
                server : {
                    host : "",
                    details : options
                }
            }, function(err, client) {
                clients.push(client);
                
                //接続出来たクライアントがmaxCount個に達するまで待つ
                client.on('connect', function(data) {
                    if ((++clientCount) == maxCount) {
                        end();
                    }
                });
            });
        }
    });
});
接続する際のパラメータを
'force new connection':true
と設定しておかないと全てが1つのコネクションとして扱われてしまいます。
パラメータさえ指定しておけば後は繋ぎたいだけforで回して接続すれば出来てしまいます。簡単!


socket.ioの認証まわりのテスト

socket.io-clientではcookieをセットすることができません。

socket.ioの接続認証はexpressのセッションIDをcookieより取得、さらにそのセッションIDを元にsessionStoreからセッションデータを取得、正しいセッションデータがあれば接続を認める、という流れになっています。

そのため、cookieが無いとsocket.ioの認証をそもそも受けられないのですが、
expressやsocket.ioのテストはこんな感じで書いてます、というお話 – アルパカDiary
という素晴らしいエントリーが合ったので参考にさせていただきました。

socket.io-client/lib/socket.js内のio.Socket.prototype.handshakeをsupport/helper.js内でオーバーライドしてしまい、
cookieをx-set-cookieというキーでヘッダに格納しているようです。

support/helper.jsに補助的なメソッドを追加&テスト用にcookieをセットする、という手法を使わせて頂き、
socket.ioの認証テストは以下のように。

var should = require('should')
  , expect = require('expect.js')
  , helper = require('./support/helper')
  , app = require('../app.js')

var options = {
    transports : ['websocket'],
    'force new connection' : true,  //別々のコネクションとして認識させるために必要
    port : app.get('port'),
};


//socket.ioの接続テスト
describe('socket.io test', function() {
    before(function(done) {
        helper.initDataStore(done);
    });
    
    it('ログイン前はsocket.ioで接続できないはず', function(done) {
        this.timeout(10000);
        helper.login({
            auth : {
                userID : 'test',
                password : 'wrong password'
            },
            server : {
                host : "",
                details : options
            }
        }, function(err, client) {
            //接続できてはいけない
            client.on('connect', function(data) {
                done("wrong behaviour");
            });
            
            //エラーが起こるはず
            client.on('error', function(data) {
                //ハンドシェイクのエラーのはず
                should.equal(data.toString(),"handshake error");
                done();
            });
        });
    });
    it('ログインした後はsocket.ioで接続できるはず', function(done) {
        this.timeout(10000);
        helper.login({
            auth : {
                userID : 'test',
                password : 'test'
            },
            server : {
                host : "",
                details : options
            }
        }, function(err, client) {
            client.on('connect', function(data) {
                //接続完了するはず
                done();
            });
        });
    });
});
helper.loginではログインしてexpressのセッションの発行を受けたのち、コールバック関数でsocket.io-clientのsocketインスタンスを返しています。

socket.ioの認証でエラーが起きるとerrorイベントが発火するためclient.on(‘error’, function(data) {})の用にしてそのエラーをキャッチするようにしたいます。
testUserはログイン済みのため接続できてconnectionイベントが発火しますが、invalidUserはログインしていないため接続できずにerrorイベントが発火します。


メッセージ交換が出来るかどうかのテストも以下のように簡単に行うことが出来ます。
    it('メッセージの送受信がclient0とclient1でできるかどうか', function(done) {
        this.timeout(10000);
        var maxCount = 2;
        var clientCount = 0;
        var clients = [];
        
        var connectCompleat = function() {
            clients[0].on("message",function(message){
                //client0が受信したメッセージはclient1が送信したメッセージなはず
                should.equal(message, clients[1].userID + ' ' + "message");
                
                //テスト終了前に切断する
                clients[0].disconnect();
                clients[1].disconnect();
                done();
            });
            clients[1].emit("chat","message");
        }; 
        
        for (var i = 0; i < maxCount; i++) {
            (function(userID) {
                var client = helper.login({
                    auth : {
                        userID : userID,
                        password : 'test'
                    },
                    server : {
                        host : "",
                        details : options
                    }
                }, function(err, client) {
                    client.userID = userID;
                    clients.push(client);
                    
                    //client0とclient1が接続するまで待つ
                    client.on('connect', function(data) {
                        if ((++clientCount) == maxCount) {
                            connectCompleat();
                        }
                    });
                });
            })('test' + i);
        }
    });

1000人同時接続のテストの際にファイルディスクリプタ最大数が原因だと気づかずにはまってしまいましたが、
それさえ忘れなければ普段クライアントで利用しているコードがサーバ側でも使えるのは便利ですね。


前々回・前回・今回のサンプルコードを全て含めたものはpxsta / express-socket.io-chat-testです。

このエントリーをはてなブックマークに追加
はてなブックマーク - socket.io-clientを用いてExpress+Socket.IOで作ったサービスへ同時接続テストを行う

mochaとsuperagentでexpressを使ったサービスのログイン周りのテスト

このエントリーをはてなブックマークに追加
はてなブックマーク - mochaとsuperagentでexpressを使ったサービスのログイン周りのテスト

前回のexpress+soket.ioでのセッション管理に続いて、今回はexpressのセッション管理のテストについて。

mochasuperagentを使えば

  • ページの表示確認(ステータスコード・ページbody本文)
  • ログインページヘのpostで正しくログイン出来るか
  • ログイン状態管理(セッションでの振り分けが出来ているか・リダイレクトが正しく行われているか)
などのログイン周りのテストが簡単に出来るようなので試してみました。

ソースコードとサンプル

コード
mochaとsuperagentを用いてexpressのアプリのログイン周りのテスト — Gist
.
├── app.js
├── chat.html
├── index.html
├── node_modules
│   ├── connect-redis
│   ├── cookie
│   ├── ejs
│   ├── express
│   ├── should
│   ├── socket.io
│   └── superagent
├── package.json
└── test
     ├── app.test.js
     └── mocha.opts


テスト対象の動作サンプル
Socket.io-Express3.0.0rc3 session sample
簡単なチャット。passwordがtestなら何でもログイン可能。やけに時間がかかるのはherokuだから?


やったこと

インストール

npm install mocha
npm install superagent
npm install should
shouldもとりあえず。
mochaについてはテストフレームワーク mocha – hokaccha.hamalog v2がとても参考になりました。

app.js側の準備

基本的に前回とほとんど同じですが、expressの設定とsessionStoreをテストコードから参照するために2行ほど書き換えます。
var app = module.exports = express();
app.configure(function() {
    //テスト用
    app.set("sessionStore",sessionStore);
});


ログインが必要なページのテスト

まず、/chatにアクセスするためにはログインが必要。
ログイン前に直接アクセスすると/にリダイレクトされるはずです。そのテストを行うコードは次のようになります。
var url = require('url')
  , should = require('should')
  , assert = require('assert')
  , superagent = require('superagent');

describe('HTTP Server Test', function() {
    //テストに使用するユーザーを作成
    var testUser = superagent.agent();
    
    it('ログイン前にチャットページにアクセスしたらログインページにリダイレクトされるはず', function(done) {
        testUser.get('http://localhost:3000/chat').end(function(err, res) {
            should.not.exist(err);
            res.redirects.should.not.be.empty;
            should.equal(url.parse(res.redirects[0], false, true).pathname, "/");
            done();
        });
    });
});
superagent.agent()でユーザーを作成して、
getでHTTP GETの要求を/chatにした後リダイレクト先が/であることを確かめています。

testディレクトリにapp.test.jsなどという名前で保存してmochaを実行すれば
$ mocha
   info  - socket.io started

  ․

  ✔ 1 test complete (17ms)
などと表示され無事にテストが通ったことが分かります。

ログイン処理のテスト

次に、/ページではログインを行います。
ログインフォームは
<form action="/user/login" method="post">
    ID: <input type="text"  name="userID" value="test"/> <br/>
    PASS: <input type="text"  name="password" value ="test"/>
    <input type="submit" value="login" />
</form>
postを受け付ける部分は
//ログイン処理
app.post('/user/login', function(req, res) {
    var postData = {
        userID : req.body.userID,
        password : req.body.password
    };
    //passがtestならログイン成功させる
    if ( typeof postData.userID !== 'undefined' && typeof postData.password !== 'undefined' && postData.password.toString() === 'test') {
        //sessionにユーザーID保存
        req.session.userID = postData.userID.toString();
        res.redirect('/chat');
    }
    else {
        console.log('login failed');
        res.redirect('/');
    }
});
のようになっていて、/user/loginにHTTP POSTでuserID, passwordを送るようになっています。

superagentではユーザーごとのcookieの管理が出来るため、セッション管理のテストもできます。
このログイン処理のテストを行うコードをmocha+superagentで書くと以下のように。
describe('HTTP Server Test', function() {
    //テストに使用するユーザーを作成
    var testUser = superagent.agent();  //正規にログインするユーザー
    var invalidUser = superagent.agent(); //ログインしないユーザー

    it('ログインに成功したら/chatにリダイレクトされるはず', function(done) {
        //ログインページに対してのPOST送信でログイン処理を行う
        testUser.post('http://localhost:3000/user/login').send({
            userID : 'test',
            password : 'test'
        }).end(function(err, res) {
            should.not.exist(err);
            res.redirects.should.not.be.empty;
            should.equal(url.parse(res.redirects[0], false, true).pathname, "/chat"); 
            done();
        });
    });

    it('ログイン済みのtestUserは/chatに直接アクセスすると/chatにアクセスできるはず', function(done) {
        testUser.get('http://localhost:3000/chat').end(function(err, res) {
            should.not.exist(err);

            //ページが表示され、それは/chatなはず
            should.equal(res.statusCode, 200);
            should.equal(res.req.path, "/chat");
            done();
        });
    });

    it('ログインしてないinvalidUserは/chatに直接にしても/にリダイレクトされるはず', function(done) {
        invalidUser.get('http://localhost:3000/chat').end(function(err, res) {
            should.not.exist(err);

            //リダイレクト先が存在し、/にリダイレクトされるはず
            res.redirects.should.not.be.empty;
            should.equal(url.parse(res.redirects[0], false, true).pathname, "/");
            done();
        });
    });
});

testUserとinvalidUserの2ユーザーを作り、testUserは.post(‘user/login’).send({userID : ‘test’,password : ‘test’})でログイン処理を。
testUserはログイン済みのため/chatにアクセスできますが、invalidUserは未ログインなため/にリダイレクトされます。

セッションストアにデータが収められているかのテスト

最後に、sessionStoreに正しくセッション情報が保存されているかどうかのテスト。
ヘッダのcookieからセッションIDを取り出して、それを元にセッションストアからセッションデータを取り出してユーザー名を確かめます。
これはsocket.ioの認証時にも同じ事をしています。

var url = require('url')
  , connect = require("express/node_modules/connect")
  , should = require('should')
  , assert = require('assert')
  , superagent = require('superagent')
  , app = require('../app.js');


describe('HTTP Server Test', function() {
    //テストに使用するユーザーを作成
    var testUser = superagent.agent();

    it('ログインに成功したらセッションストレージにユーザー名が保存されているはず', function(done) {
        testUser.post('http://localhost:3000/user/login').send({
            userID : 'test',
            password : 'test'
        }).end(function(err, res) {
            should.not.exist(err);
            
            //sessionStoreにsessionデータが保存されているはず
            var header_cookie = res.req._headers.cookie;
            var cookie = require('cookie').parse(decodeURIComponent(header_cookie));
            cookie = connect.utils.parseSignedCookies(cookie, app.get('secretKey'));
            var sessionID = cookie[app.get('cookieSessionKey')];
            
            app.get("sessionStore").get(sessionID,function(err,session){
                 should.not.exist(err);
                 
                 //userIDがログイン時のものと一致するはず
                 should.equal(session.userID,"test");
                 done();
            });
        });
    });
});
sessionStoreにセッション情報が保存されていることを確認。

と、いうことで、mocha+superagentを使えばログイン処理まわりのテストも簡単に出来そうです!
superagentを使えば複数人の接続のテストも出来るかと!

今回のサンプルコードはここにまとめて置いておきました。
https://gist.github.com/3968061

このエントリーをはてなブックマークに追加
はてなブックマーク - mochaとsuperagentでexpressを使ったサービスのログイン周りのテスト

BOTアイデア

このエントリーをはてなブックマークに追加
はてなブックマーク - BOTアイデア

仕様未定のまま書くとか何やってるんだ
とはいえ考える時間がない

とりあえず書き出してみる。
書きながら整理できるかもしれない。

イメージ的には
リプライ受け取る→形態素分析、名詞抜き出す→その名詞に関連した名詞使ってリプライメッセージ作成→リプライ

みたいな。
関連語句はYahoo関連検索ワードAPI使う。
DBには固有なIDを振りつつ名詞を登録、関連語句のIDもセットで登録。

じゃあ関連語句がDBに登録されてなかったらどうするのか。
新たに追加するとして、その関連語句がまたもや登録されてなかったら……

登録して登録して登録して………終わりを迎えるのか?コレ。


それともYahooのAPIが1日に50000回までリクエスト可能だから、
50000回ほど回して予め辞書作っておくか?

今更だがこれが良さそうだな。
あとはDBのサイズがどれくらいになるかか。
まあ100文字が60000行あっても44MBだったから問題なさげだな。

よし、まずは辞書作って、リプライメッセージ作成時にDBクロールして万が一なかったら新たに追加。

ついでにテンプレ的なもの作って起きたいなあ

というかマルコフ連鎖組み込むか。
そうしよう。

その時に関連語句DB使おう。

明日は外出するから移動時間ばかりだ。
そのときに更に考えてみよう。

ちなみに携帯からだと連続改行むしされるみたいだから

使ってみた。

↑2てすと。

↑3てすと。
というか文字数足りないw

このエントリーをはてなブックマークに追加
はてなブックマーク - BOTアイデア

Dansette