はじめに こんにちは！最近転職して新宿までロマンスカーにお世話になりっぱなしの ikasam_a です。 Test Track 3日目です！初日に xaicron さんから「テストの細かい話を書いて！」と言われたので、今日はちょっと趣向を変えて、テストの分類についてつらつらと書いてみたいと思います。 あまり、というかまったく Perl の話は出てこないです！さーせん！ テストを分類すると捗るぞ 例えばチームでテストの話をするような時に、それぞれが考える「テスト」のイメージが違って、話が噛み合わないことがあったりしますよね。僕はよくありました。 僕は「テスト＝単体テスト」の話をしているつもりが、相手は「テスト＝機能テスト」だと思って話を進めていると、あれ？という場面があったりします。こういうときは、例えば設計におけるデザインパターンのように、テストをより具体的にした共通認識があると話が捗りま
本日行われた Shibuya.js の発表資料をアップしました。 さいきんの JavaScript テスト / Test.js - Shibuya.js 発表資料 View more presentations from hotchpotch JS のテスティングフレームワークのおおざっぱな説明や JavaScript テストにおける問題、それについての解決方法の一つ、CUI でのテスト、Envjs、エンドツーエンドテストにおける JS / Ajax のテスト、終わりにちらっと Phantomjs の話があります。 スライドの最後にあるように、やはりまだコレだ！という JS のテスティングフレームワークは存在しなく、今後 JS のテストは『僕らが書きたいテスト』をどれだけ簡単に書ける・書く手法が確立されるかによって流行廃りは決まってくるんじゃないかなぁ、と思ってます。そのうちの一つがスライ
「書く書く詐欺」になりつつあった、googletest 1.5.0の解説。ようやく着手です。 今までは、「./configureしてmakeしてsudo make installすればOK」…という具合にやってきていたんですが、Version1.5.0ではこの方法を正式には採用しない方針に変更したようです。 そのように考えた理由がここに書かれています。 Google グループ 要は。コンパイル済みのライブラリを作ってしまうと、コンパイル条件を変更したいときとかに追従できなくていろいろ悪さする可能性があるから、ということのようです。で、テストをビルドするときにgoogletestのコードも一緒にコンパイルしてくださいな、ということみたいです。 READMEファイルの内容とgtest-1.5.0/src/Makefileの焼き直しですが、Version1.5.0のビルドの仕方を簡単に説明。 直
Test::TCP の中で exec 発行すれば、groonga だろうと KT だろうと memcached だろうと、サーバープロセスのテストは簡単にできるのであって、サーバーごとにモジュールにする必要はない。以下は、groonga をテストする例。 Test::TCP は、さまざまなTCPサーバーのテストにつかわれており、さまざまな BK をふくんだ実装となっていて、これを再発明しようとすると、意外とめんどくさかったりするので、素直につかうとよいです。 use strict; use warnings; use utf8; use Test::More; use Test::TCP 1.08; use File::Temp (); use File::Which; my $bin = scalar which 'groonga'; plan skip_all => 'groonga
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く