タグ

testに関するlibkazzのブックマーク (18)

  • Close to the EDGE 任意のファイル名とディレクトリ名の fixturesが読み込めるようになった

    Railsの fixturesはたいへん便利な仕組みなのだが、今までは決められた名前のディレクトリ($RAILS_ROOT/test/fixtures/)内の決められた名前(テーブル名と同じ名前)のファイルしか読み込めないという制約があったため、例えば複数パターンのテストデータを用意しおいて切り替えて DBわせたいような場合なんかに、ちょっと不便に感じることがあった。 が、最近の edgeでは2箇所ほど fixtures関連の修正が入っており、fixturesの使い勝手が向上している。 1. サブディレクトリ内の fixturesを読み込む rakeタスク まず、fixturesをディレクトリで分けて複数用意してディレクトリ名を指定して読み込む rakeタスクが 実装された 。 例えばこんな fixturesファイルを用意して、 test/fixtures/users.ymljoh

  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
    libkazz
    libkazz 2010/08/09
  • 第1回 組み合わせテストの技法 | gihyo.jp

    はじめに-この特集のねらい この特集では、ソフトウェアの組み合わせテストについての技法である「オールペア法」と、オールペア法を採用したテストケース作成ツール「PICT」の機能、およびその効果的な使い方を、多くの例を用いて解説していきます。筆者はPICTを実際のテスト業務に1年半以上使用してきました。そこから得られたノウハウも合わせて公開したいと思います。 ソフトウェアはさまざまな因子(パラメータ)の組み合わせにより、その挙動が違ってきます。これらパラメータの組み合わせを総当りで行うことはテスト件数の爆発を招き、実際に行うのは多くの場合、不可能です。どのようにすればテスト件数の爆発を招かずに、しかもテストの質を落とさない組み合わせをテストできるかが重要な課題となっています。 こうした課題を解決するために考え出された効率的な組み合わせテスト技法は、大規模、複雑化するソフトウェアの組み合わせテス

    第1回 組み合わせテストの技法 | gihyo.jp
    libkazz
    libkazz 2010/08/09
  • Efficient data transfer through zero copy

    JavaDevelop modern applications with the open Java ecosystem.The Java programming language is a high-level, object-oriented language. It is rapidly evolving across several fronts to simplify and accelerate development of modern applications.

    Efficient data transfer through zero copy
    libkazz
    libkazz 2010/08/09
  • RSpecでテストコードを書いたまとめ - (゚∀゚)o彡 sasata299's blog

    2009年07月01日01:07 Ruby RSpecでテストコードを書いたまとめ 最近は Ruby のテストに興味があっていろいろ試しています。 今気になっているのは RSpec と Cucumber の2つ。今回はまず RSpec を色々触ってみたのでそのときのログをメモってみます。RSpec については RSpec + Autotest::screen = 最高の開発環境 でも書きましたが、BDD(振舞駆動開発)のフレームワークで、describe と it という2つのメソッドを利用します。describe にテストしたい振舞を書き、it にはそのときに満たすべき仕様を書くという感じです。今回は Rails で RSpec を使ったテストを書いてみましたよ。(=゚ω゚)ノ 事前準備として、rspec と rspec-rails と Zentest(テストを自動で走らせるため。この中

  • テストダブル - Martin Fowler's Bliki in Japanese - TestDouble

    http://martinfowler.com/bliki/TestDouble.html Gerard Meszarosが、様々なXunitフレームワークを使用したパターンを集めた書籍を執筆中である。 彼は、ある厄介なことに出くわしている。 システムの一部分をテストするためにスタブ化することがあるが、 その名前というのが、スタブ、モック、フェイク、ダミーなど、色々とあるのだ。 そのため彼は、自身の用語集を作成した。 この用語集は広く普及すべきものだろう。 彼が一般的な用語として使っているのは、「Test Double(テスト代役)」という言葉だ(スタントの代役(double)を想像してほしい)。 Test Doubleは、テスト用にオブジェクトを入れ替えるときに一般的に用いられる言葉である。 Gerardが作成したリストには、様々なDoubleが載っている。 ダミーオブジェクトは、受け渡

    libkazz
    libkazz 2010/02/20
    モックとスタブの違いまとめ
  • SAStruts で test をするの巻き - h-kageyuの日記

    こんな感じだろうとおもってやったら出来た。 すげー簡単。 package sabbs.action; import java.util.List; import javax.servlet.http.HttpSession; import javax.transaction.NotSupportedException; import javax.transaction.SystemException; import javax.transaction.UserTransaction; import org.junit.Before; import org.junit.Test; import org.seasar.extension.jdbc.JdbcManager; import org.seasar.extension.unit.S2TestCase; import org.seasa

    SAStruts で test をするの巻き - h-kageyuの日記
  • はてなブログ | 無料ブログを作成しよう

    カブを後輩に譲った話 僕がはてなブログを始めて最初の記事がこれ。当時は大阪に暮らしていたので大阪生活という名前でブログをやっていた。現在は社宅に居るから社宅生活。引っ越したらまた次のブログに引っ越すよ。 ジムに通っていた頃には週4以上で乗っていたけれど、最近忙しくてここ一…

    はてなブログ | 無料ブログを作成しよう
    libkazz
    libkazz 2009/06/04
  • とあるコンサルタントのつぶやき - Site Home - MSDN Blogs

    MCS (Microsoft Consulting Services) の某コンサルタントがまったり語るテクノロジのお話です。 触って覚える Microsoft Azure 今日から TechSummit 2018... Date: 11/05/2018 Docker for Windows & Web Apps for Containers 実践活用技法 先日、しれっと営業部門のクラウドソリューションアーキテクトに異動した話を書いたのですが、このロールは Azure... Date: 09/27/2018 Agile も DevOps も銀の弾丸なんかじゃない ……と、のっけから噛みつかれそうなタイトルを掲げてみたのですが;、ここ最近、立て続けて数件、「いやそれはアジャイルとか無理だろ;」的な話があって、ちょっとエントリを書いてみようかと思った次第。どんな話... Date: 08/28

    とあるコンサルタントのつぶやき - Site Home - MSDN Blogs
    libkazz
    libkazz 2009/03/10
    エラー設計がとても分かりやすい(業務処理もコントローラで例外ハンドリングするのがよいかどうか、もう少し読んで考えたい)
  • ITの地殻変動はどこで起きているのか?~チケット駆動開発はなぜ生まれたのか - プログラマの思索

    2009年になって、ITの地殻変動がどこに起こっているのか?を考えてみる。 #ラフなメモ書き。 【参考】 InfoQ: Martin Fowler氏が語る陥りがちなスクラムの落とし穴を避ける方法 InfoQ: 複数のアジャイルチームでのバージョン管理 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) 【アジャイル開発の問題点】 1990年代後半から、サーバー+クライアントの2層方式を基とするVBアプリからMVCを基とするWebシステムへのリエンジニアリングがあった。 更に、システムが大規模化して、開発期間が短くなるSW開発の現場。 RUPなど、イテレーティブな開発プロセスの重要性が叫ばれるものの、実際の現場で運用するにはハードルが高かった。 2000年頃出現したXPは、ソフトウェアの歴史の中で、オブジェクト

    ITの地殻変動はどこで起きているのか?~チケット駆動開発はなぜ生まれたのか - プログラマの思索
  • Unit testing - 清水川Web

    原文: Unit testing — plone.org UnitTestは、Plone 2.1の機能として厳密はに定義されていないが、これは非常に重要な "良い手法" であり、慣れ親しんでおくべき事だ。Ploneは広範囲にわたってUnitTestを実施している(UnitTest無しでPloneのコードをチェックしようとしてはいけない, 時間がいくらあっても足りない)。ここでUnitTestの導入について簡単に説明しよう。さあ、始めよう! UnitTestのアイディアは、ソフトウェアの部品が集まり複雑に結合してくるとテストがだんだん難しくなってくるという点にある。君がPloneのUI上で動作する自身の製品をテストしていて何かをおかしくしてしまったとき、以前に動作していたと思われる全てのテストを再度行おうとすることはとても難しい事だ。 UnitTestには以下のゴールデンルールがある 一つの

  • MOONGIFT: » ブラウザをターミナルから操作して自動テストを実現「Firewatir」:オープンソースを毎日紹介

    Webアプリケーションのテストは面倒くさい。HTTPでゲットするだけであれば良いが、ポストしたり、JavaScriptでレンダリングしてあったりと、動作も複雑だ。それらを全て網羅的にテストするのはなかなか難しい。 自動操作中 そこでテストにブラウザを使ってみよう。自動操作することで、テストの効率化をはかれる。 今回紹介するオープンソース・ソフトウェアはFirewatir、Firefoxを自動操作するソフトウェアだ。 FirewatirはIEをRubyを使って自動操作するソフトウェア、WatirのFirefox板とでも言うべきソフトウェアだ。実際、読み込むファイル等は違えども全体的な操作はWatirと同じスクリプトで動作する。 操作中のターミナル 実際の使い方はFirewatirの提供するXPIをFirefoxにインストールし、JSSHを起動する。そしてGemを使ってFirewatirをイン

    MOONGIFT: » ブラウザをターミナルから操作して自動テストを実現「Firewatir」:オープンソースを毎日紹介
  • 極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ

    今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる

    極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
    libkazz
    libkazz 2008/04/24
    リファクタ・保守・レグレッションを考えなければ
  • ウノウラボ Unoh Labs: オープンソース戦略により、無償で使えるようになった負荷テストツール

    GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー!古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠

    ウノウラボ Unoh Labs: オープンソース戦略により、無償で使えるようになった負荷テストツール
    libkazz
    libkazz 2007/05/17
    使ってみたい
  • Java

    JavaDevelop modern applications with the open Java ecosystem.The Java programming language is a high-level, object-oriented language. It is rapidly evolving across several fronts to simplify and accelerate development of modern applications.

    Java
  • Ruby スクリプトのユニットテスト・チュートリアル - WebOS Goodies

    WebOS Goodies へようこそ! WebOS はインターネットの未来形。あらゆる Web サイトが繋がり、共有し、協力して創り上げる、ひとつの巨大な情報システムです。そこでは、あらゆる情報がネットワーク上に蓄積され、我々はいつでも、どこからでも、多彩なデバイスを使ってそれらにアクセスできます。 WebOS Goodies は、さまざまな情報提供やツール開発を通して、そんな世界の実現に少しでも貢献するべく活動していきます。 少し前に公開した Ruby 用 JSON クラスに数多くのバグを仕込んでしまい(たいへんご迷惑をおかけしました m(_ _)m)、テストの重要性を改めて痛感している今日この頃です。今後も開発を続けるにあたって、現在の行き当たりばったりなテスト方法ではとてもやっていけないと危機感を持ちまして、きちんとしたユニットテストの方法を調べてみました。 で、実際に試してみたと

  • 【レビュー】これは凄い! Ajax最強のデバッグツール"FireBug 1.0"リリース (1) デベロッパのアツい視線を受ける実力派エクステンション (MYCOMジャーナル)

    デベロッパがFirefoxを使う理由はエクステンション! Ajax Webアプリケーションの開発者には、WebブラウザとしてFirefoxを愛用しているユーザが多い。その理由のひとつに豊富なエクステンション機能が挙げられる。Firefoxを使っているからエクステンションを使っているというよりも、エクステンションを使いたいからFirefoxを使っているという感じだ。 デベロッパに人気のあるエクステンションはいくつもあるが、代表的なところではAll-in-One GesturesやDictionarySearch、Greasemonkey、User Agent Switcher、ScrapBookなどを挙げることができる。そしてAjax Webアプリケーションの開発において必須ともいえるエクステンションに、Firebugがある。 Firebugに対する称賛の声は枚挙にいとまがない。「Fireb

    libkazz
    libkazz 2007/02/07
    FireBugの説明
  • Rails勉強会@東京 第9回 - 辺境の日々 (旧:世界線航跡蔵)

    形式は前半・後半に時間を区切って オープンスペース 形式。要 ポジション・ペーパー というのも変わらず。 この形式はいいんじゃないかなと思ってる。最初、秋葉原でやっていた頃、参加者全員が集まって座れる場所を確保できなかった故に 角谷さん の発案でオープンスペースになったそうだけれど( 第0回 )、これによって、最多で10人程度に分かれるから参加者のコミュニケーションが促進されてる。Listen Only Memberを発生しにくい仕組みになってるんじゃないかと思う。 反面、少数であるが故に全員が受け身だとひたすら沈黙になってしまうのは確か。一時期、そういう感じでいつまで経ってもセッション案が出なかったりしたけれど。でも、 もろはし さんの提言で事前にセッション案を十分に出しておくというのが復活して、そういう難点は解消されつつある。 ポジション・ペーパーについてはこれはよい作用をしているのは

    Rails勉強会@東京 第9回 - 辺境の日々 (旧:世界線航跡蔵)
    libkazz
    libkazz 2006/11/13
  • 1