タグ

testingに関するtokadaのブックマーク (58)

  • JSCoverage - code coverage for JavaScript

    Note: Any future development of the JSCoverage code base will likely occur in the new JSCover project on GitHub, which reuses a substantial amount of JSCoverage code and aims for a high degree of backward compatibility with JSCoverage. JSCoverage itself is unlikely to have any further releases. JSCoverage is a tool that measures code coverage for JavaScript programs. Code coverage statistics show

  • 第37回 実用的なダミーサーバ ww(double-web)(2) | gihyo.jp

    前回(第35回)はwwを使ってWebのダブルとなるサーバを作り、スパイ機能を使ってクライアントからのリクエストの状況を目視確認する方法を説明しました。 今回は、ミニブログへのメッセージ投稿を通じて、wwを自動化テストに組み込む方法を説明します。 RSpecの自動テストの中からサーバを起動停止する wwは、単一のサーバプロセスとして起動させるほかに、自動化テストの中で定義・起動・停止するためのAPIを備えています。前回作ったダブルサーバを、RSpecから起動・停止するテストコードは次のようになります。 # spec/miniblog_client_spec.rb $:.unshift File.expand_path("../lib", File.dirname(__FILE__)) require 'miniblog_client' require 'ww' describe Minibl

    第37回 実用的なダミーサーバ ww(double-web)(2) | gihyo.jp
  • 第35回 実用的なダミーサーバ ww(double-web)(1) | gihyo.jp

    はじめに Web APIを使って様々なサービスと連携するというアーキテクチャはすっかり定着した感があります。みなさんも、Web APIを使ってデータをやりとりするアプリケーションを書く機会も増えているのではないでしょうか。 Web APIを使うアプリケーションの開発では、テストやデバッグをする際のAPIアクセスが悩みどころとなります。物のサーバを使ったのではテストデータの初期化などに手間がかかりますし、逆にHTTPアクセス自体をスタブやモックを使って間接化してしまうとそれが当に有効なテストなのか不安が残ってしまいます。 筆者も、仕事やプライベートでのコーディングでこのような悩みに何度も遭遇しました。これらを解決するために開発したのがwwです(wwと書いて'double-web'と読みます⁠)⁠。 ダミーWebサーバ作成ライブラリww(Double Web) wwは、Webサービスの簡単

    第35回 実用的なダミーサーバ ww(double-web)(1) | gihyo.jp
  • 离开世界的方式,我自己选-游戏三昧网

    离开要合理确定集团办学规模。 广东消委会:世界式科学看待“低糖”电饭锅功能效果对健康饮是否真有帮助?为掌握“低糖”电饭锅产品真实情况,世界式引导科学消费,推动行业健康发展,广东省消委会于今年3月至7月联合佛山市消委会,委托第三方检测机构——威凯检测技术有限公司,开展了“低糖”电饭锅商品比较试验。次比较试验20款测试样品,己选均由消委会工作人员通过线上线下渠道,己选模拟实际消费购得,价格从198元/台到1699元/台不等,覆盖高中低档产品,基涵盖了市场上“低糖”电饭锅产品的主流品牌和重点型号。 为突出针对性、离开实用性、离开客观性,次比较试验在测试产品安全性的基础上,重点选取了蒸煮米饭的还原糖含量、抗性淀粉含量两项行业认可度高、性能代表性强的功能指标进行测试,并加入了针对米饭形态、色泽、滋味、香气和口感等维度的主观测评环节。从比较试验结果来看,世界式在功能效果方面,世界式20款样品中

  • TddAntiPatterns - TDD のアンチパターン

    TddAntiPatterns - TDD のアンチパターン 目次 この文書について TDD のアンチパターン TDD アンチパターン・カタログ 嘘つき。 (The Liar) セットアップ過多 (Excessive Setup) 巨人 (The Giant) モック酔い (The Mockery) 検査官 (The Inspector) 太っ腹な残り物 (Generous Leftovers) 地元の英雄 (Local Hero) 小姑 (The Nitpicker) 秘密のキャッチ (The Secret Catcher) ペテン師 (The Dodger) 大声 (The Loudmouth) はらぺこキャッチ (The Greedy Catcher) 序列屋 (The Sequencer) 隠れ依存 (Hidden Dependency) 点呼 (The Enumerator)

  • RSpecでGrowlなテスト環境♪ - (゚∀゚)o彡 sasata299's blog

    2009年12月29日08:34 Ruby RSpecでGrowlなテスト環境♪ mac で Growl な環境で、テスト環境を構築してみます。利用するライブラリは以前も紹介しましたが、rspec + rspec-rails + autotest(ZenTest) です。で、.autotest をこのように設定しました。これでテストの度にその結果を Growl で通知してくれるようになります。 require 'autotest/redgreen' #require 'autotest/growl' IMG_OK = '~/.autotest_icons/rails_ok.png' # 成功時の画像 IMG_NG = '~/.autotest_icons/rails_fail.png' # 失敗時の画像 IMG_PD = '~/.autotest_icons/syatyou.jpg' #

  • fixture replacement 決定戦 - ヽ( ・∀・)ノくまくまー(2009-12-22)

    めも FGはdefineの仮引数周りが無駄 (blueprintで改善) FGはinstanceをフラットに管理しすぎ FGのsequence(next)はイケてる FGはAR前提 Machinistは定義がイケてるが、名前がダサイ(make_unsaved) Machinistはメソッド名が衝突しそう(makeはアカン) Machinistはinstanceをクラス毎に分類できるが、Shamレベルまで落ちるとフラットになる片手落ち感 Daddyの使えなさは異常 FGの継承はどうやるの?(-> :parent) FG.blueprint は :parent を理解してくれない 試行錯誤 Factory.sequence :login do |i| "login#{i}" end Factory.define(:user) do |user| user.login {Factory.next

  • InfoQ: Bobおじさんが述べるTDDの適用可能性

    原文(投稿日:2009/11/04)へのリンク "TDDによってペースが鈍ると考えている人は石器時代で生きつづけているようなものだ"と主張したことで議論を巻き起こしたブログに続き、Bob Martin氏は現実のTDDの適用可能性、役割、恩恵に対する深い洞察を試みている。 氏はまず"TDDはアーキテクテャの代替物か?"という大きな問題を取り上げ、実例を背景に「そうではないですが、しかし...」と答えている。 いちから始めて次々にテストケースを書いていくことで実行可能なアーキテクチャを生成できるという意見は全くばかげたことです。テストしないという決断を下す必要もあります。 もちろんこれらの決断の多くはできるだけ先延ばしにすることができるし、そうすべきです。例えば、データベーススキーマは恐らく長い時間待つことが可能なものです。Spring、JSF、Hibernate、JPAなどを使うかどうかの決

    InfoQ: Bobおじさんが述べるTDDの適用可能性
  • 【レポート】jQueryテストスイート「QUnit」がスタンドアロン化! 使い方を早速チェック (1) QUnitとは? | エンタープライズ | マイコミジャーナル

    jQueryでユニットテストをおこなう - QUnitとは 高機能・軽量のJavaScriptフレームワークで、デベロッパにも人気の高いjQuery。そのjQueryをベースとしたテストスイートに「QUnit」がある。 QUnitはJohn Resig氏とJorn Zaefferer氏が中心となって開発をおこなっているユニットテスティングフレームワーク。デベロッパはQUnitを使うことで、jQueryを使ったJavaScriptコードを書くように、簡単にテストを記述できるようになる。同ライブラリはjQueryと同じく、The MIT LicenseとGNU GENERAL PUBLIC LICENSE Version 2のもとで公開されている。 去る9月29日(米国時間)、開発者であるJohn Resig氏はTwitter上で次の3点をアナウンスした。 QUnitはjQueryに依存した実

  • Google App Engineでテスト駆動開発を行うための3つのTips | TRIVIAL TECHNOLOGIES 4 @ats のイクメン日記

    Google App Engineの開発ではPythonを使います。GAEを使ったWebアプリの開発でテスト駆動開発を行う際にも,Python的なユニットテストの文脈を活用できます。 ただし,GAEでユニットテストを行うためにはいくつかのツールやトリックが必要です。ここでは,そのテクニックを簡単に紹介します。 その1 : NoseGAEを使う Pythonのテスト用ツールにNoseがあります。このツールは,複数のディレクトリを渡り歩いて,複数のテストコードを一気に実行してくれる便利なツールです。 NoseのプラグインNoseGAEをインストールすることで,GAEアプリのテストを楽に行うことができます。「nose --with-gae」というようにオプション指定をすることでNoseGAEを利用できます。NoseGAEでは,テストコード上でGAEのモジュールやパッケージをインポートするために必

  • ricollab Web Tech Blog » Blog Archive » Mock と Stub について

    初めまして、リコーの沖田です。この度私もこの blog を書くことになりました。以後よろしくお願いいたします。 みなさんテストは好きですか?私も含めて私の同僚は皆テストが大好きなので、しばしばテストの議論で白熱しすぎてしまいます。今日はそのテストの中から Mock(モック) と Stub(スタブ) について書いてみたいと思います。 Test Double まずテストにおける Mock と Stub についてですが、これらは Test Double という概念の一部です。Double とは代役という意味で、テスト対象となるシステムが依存する外部のコンポーネントの代わりに、それらしく振舞ってくれるコンポーネントを代役として利用しようということです。 例えば Web アプリの Controller の単体テストがしたい場合に、Model の実装が完了するまでテストができないっていうのでは大変です

  • mysql と drizzle の負荷テストツール「skyload」が凄い! - kazuhoのメモ置き場

    tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql

    mysql と drizzle の負荷テストツール「skyload」が凄い! - kazuhoのメモ置き場
  • TDD、TDDと言うけれども。TDDのダークサイドについてそろそろ一言語ってみる。 - Fly me to the Luna

    id:t-wadaさんの話の中で、TDDが品質を保証するわけではない、という話があったんですが、それについて私見をつらつらと。ちなみに自分は2年くらい仕事でTDDをやってきました。 やってきた中で下記のTDDの利点を感じることができました。 その時に気づいた最もシンプルなコード、クリーンなコードができる テストコードからコードを書く、と言うのはプロダクトコードの利用方法が考えられるのでとても有効に作用します。id:t-wadaさんもリファクタリングが一番重要と話されていましたが、テストコードがあれば安心してリファクタリングができます。 より高い品質のコードが書けるようになる これはt-wadaさんの話の中でもありましたね。なぜかと言うと、プロダクトコードが実行される時の前提条件を知ろうとすると、結構いろいろなコードに目を通すことになります。コードに目を通すことで優れた先人の知恵を見つけるこ

    TDD、TDDと言うけれども。TDDのダークサイドについてそろそろ一言語ってみる。 - Fly me to the Luna
  • http://www.func09.com/wordpress/archives/532

  • ヽ( ・∀・)ノくまくまー(2009-04-08)

    やはりテストの話題になって stubとmockの違いを1行で! 今のテストフレームワークのお薦めは? RRが熱いよ!(英語ぽく書くのが目的じゃない、rubyぽいdslが必要なんだ!) mock で should_receive でガチガチにサブオブジェクトに介入してくる人って何なの! duck type の考え方からしても、何をやるかは相手に任せるベッキー mock は探針であるべきだ stub しか使わないよね ごめん、俺、最近は実データ派に戻ってきたんだ(Fixtureラブ) Fixture はシナリオ別に使い分けるのが面倒じゃない? そこで FactoryGirl ですよ 何が嬉しいの? テストデータを ruby コードで動的に書きたいときがある それって、もし fixture を簡単に切り替えられる機能があれば不要じゃね? 動的なら YAML でゴリゴリ書く方法もあるし 切り替え、

  • GitHub - btakita/rr: RR (Double Ruby) is a test double framework that features a rich selection of double techniques and a terse syntax.

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - btakita/rr: RR (Double Ruby) is a test double framework that features a rich selection of double techniques and a terse syntax.
  • ヽ( ・∀・)ノくまくまー(2009-03-30)

    ● [テスト] should change に見る UnitTest と RSpec の違い Yugui さんに Proc#should change が便利だと教わった。 Spec::Matchers::Change Spec::Matchers::Change を使うと、一連のコード(proc)実行時に変化したこと(仕様)を簡単に記述することができる。 should change(receiver, message, &block) should change(receiver, message, &block).by(value) should change(receiver, message, &block).from(old).to(new) should_not change(receiver, message, &block)

  • ソフトウェア・テストの技法は良い本 - I am Cruby!

    前田さんに「すべてのプログラマは読むべき一冊.いかに我々が進歩してないか分かるよ」とお勧めされたので読んでみた. ソフトウェア・テストの技法作者: G.J.マイヤーズ出版社/メーカー: 近代科学社発売日: 1980/03メディア: 単行  テストとは,エラーをみつけるつもりでプログラムを実行する過程である. という痺れる言葉が記されている. とまぁ,テストの部分はふむふむなるほどという感じ. 個人的に興味深かったのはデバッグの章.あまりにいいので,メモを取りながら読んだ. というかこれ,40年くらい前に書かれたものなんだねぇ...信じられない..  = デバッグの原則 == エラーの位置発見の原則 === 考えよ. デバッグのもっとも有効な方法は,エラーの兆候と関係ある情報を頭の中で分析する事である. 効率の良いデバッガはコンピュータに触れずにエラーの場所を見つけなければならない. =

  • TOEFL iBT は会場を慎重に選ぶべき - 武蔵野日記

    に付き合って TOEFL iBT を受験する。昔 TOEFL は紙ベースの試験だったらしいのだが、自分が初めて受けた2002年当時はすでにコンピュータベースの試験(CBT)になっていて、最後に受けた2005年以降インターネットベースの試験(iBT)になっていたのであった。iBT といっても試験会場まで行かないといけないし、前のように平日も含めいつでも受けられるようになっていないので、サービス後退した気がする。 iBT の目玉はライティングとスピーキングで、これまで TOEFL では選択式の読解問題とリスニングと筆記試験だけだったのだが、筆記試験が拡充された(これまでは1問だったのが2問に)のと、以前は存在しなかった喋る試験が導入されたことが大きく違う。 新しい試験になって受けたのは初めてなのだが、CBT のときは260点だか270点だか取れていたのでなめていたら、読解問題で時間が足りない

    TOEFL iBT は会場を慎重に選ぶべき - 武蔵野日記
  • autotest_screenをリリースしました。

    autotest/screenの切り出しを引き受けてから早2週間、やっとのことでリリースしました。 RubyForge: autotest_screen: Project Info Autotest::Screen shows autotest/autospec progress on GNU Screen’s status line. これからは gem install autotest_screen でどうぞ。 RubyForgeにプロジェクト作ってファイル上げてって流れ、komagataさんの動画がリアルでおすすめ。

    autotest_screenをリリースしました。