第3回次期バージョン1.8に見るTestLinkの過去・現在・未来 TestLink日本語化部会 2008-10-17
第3回次期バージョン1.8に見るTestLinkの過去・現在・未来 TestLink日本語化部会 2008-10-17
みなさま、もうすぐ今年の 2/3 が終わる今日この頃、いかが並列にお過ごしでしょうか。 私も快適に並列を生きていくために、今回 parallel_tests から test-queue に乗り換えようという気持ちになったということをご報告致します。 経緯 現在、仕事をしており、 最近ようやく富豪な Docker ホスト環境に触れるようになったということもあって、 以前試した Selenium Grid + Docker でがりがり高速化に勤しんでいます。 そんなこんなで RSpec の同時並列実行もしないとね、ということで、以前から触っていた parallel_tests を導入しました。 これまでは全テストの完了まで 約40分 かかっていましたが、parallel_tests を導入するだけで 約1
ソフトウェアの組み合わせテスト技法の１つであるペアワイズ法（Pairwise法）（またはオールペア法（All-pairs法）ともいう）と直交表を採用した組み合わせテストケース生成ツール PictMasterの使い方をはじめ、テスト全般のトピックスを掲載していきます。 PictMaster は事実上日本国内で唯一、直交表を用いた組み合わせ生成をサポートしているフリーでオープンソースなツールです。約300種類の直交表テンプレートを内蔵し、モデルに最適なテンプレートを決定してテストケースを生成します。またMicrosoftのフリーソフトであるPICTと大阪大学の土屋教授が開発したフリーソフトであるCIT-BACHをペアワイズ法（オールペア法）の組み合わせ生成エンジンとして使用しています。さらに独自の機能追加を行なったExcelベースのフリーソフトです。 無償でPictMasterを公開する理由は
今日は木曜日だったので、ハンバーグの会（Okayama.rb）に参加してきました。 今日は@mako_wisにテストの書き方について相談を受けたので、粒度とかについて説明しましたが、私は説明し始めると早口になってしまうので詰め込みすぎたかもしれないと思ったのでちょっとまとめておこうと思いました。ちなみに、書き方といってもRSpecの始め方とかではないです。その点はあしからず。 Railsプロジェクトのいいところは、テストがとてもしやすいところだと思います。 私は今の会社に入るまで、テストは書きたいけれど、どう書けばいいのかわからなかったのと、頑張って書いてみたものの、成果が周りに評価されなかったのでこのままでいいのだろうか？と思い悩んでいました。しかし、既にテストがあるプロジェクトに入って書き方を学べた事と、同僚とThe RSpec Book読書会を社内で開いて勉強したおかげで、結構綺麗に
技術部アルバイトの鈴木(@draftcode)です。 クックパッドが内部向けに開発・運用を行ってきた、分散テスト実行システムRRRSpecをオープンソースとして公開しました。RRRSpecは時間のかかる自動テストを分散処理することで、全体のテスト時間の短縮を狙うアプリケーションです。現在クックパッドでは17000を超えるテスト項目があり、マシン一台でテストを実行すると完了まで数時間かかります。このテストを60並列程度の分散処理で行うことで、平均8分から9分程度で完了できるようになりました。また、Amazon EC2のスポットインスタンスを利用することにより、大幅なコスト削減も同時に達成しました。 https://github.com/cookpad/rrrspec 分散テスト実行とは アプリケーションが大きくなるにつれて、自動テストの数も大きくなっていきます。クックパッドでは、非常に多くの
Editor's Notes\n\n\n\n\n\nテスト時間は早ければ早いにこしたことはない。全部のテスト&#x
3. MockとStubとは Test Doubleという概念の一部。 Double とは、代役のことで、テスト用にオブジェクトを 入れ替えるときに一般的に用いられる言葉。 [1] xUnit Test Patterns by Gerard Meszaitpatterns.com/Test%20Double.html 4. Test Doubleの種類 Dummy 受け渡されることはあるが実際に使用されることはない。パラメータリ ストを埋めたいだけといった場合に利用されることが多い。 Fake 実際に動作するように実装されてはいるが、手抜きされており製品版 には向かない。 Stub テスト時の呼び出しに対してあらかじめ決められた値を返すもの。 Spy 呼び出しに基づく情報を記録するスタブ。例えば、何通メールが送ら れたかだけカウントするメールサービスなどが該当す
Railsエンジニアになってから1年半くらいが経ち、社内のRailsのプロジェクトを全部で5つくらい触って、今やってるAbilie*1でようやく人並みにテストを書いてる気がしてきたので、現時点でやってるテストの方法をまとめておく。 テストのルール的なの rspecでは必ずモデルのテストは書くようにしてる。ヘルパーも大体書いてるけど、コントローラやルーティングのテストはあまり書いてない。 というのも、コントローラーのコードを極力短くしてモデルを太らせているのでコントローラのテストはあんまり意味が無い気がしていて、その代わりにCapybaraでテストを書いておけば十分なんじゃないかなと思ってきたから。Capybaraは書いてるので、そういう意味では書いてるとも言える。 社内の管理者だけが使える管理画面も作ってるけど、そっちはテストあんまり書いてない。ここは動かなくなっても一般ユーザーには影響が
今回は「Jenkins CI」のお話 http://jenkins-ci.org/ きっかけはGunma.web #4でのLTでした Gunma.web #4 (on 2011/02/12) まとめ - ぱろっと・すたじお Jenkins CI（旧Hudson）の話を最初に聞いたのはデブサミ2009？だったと思いますが、 本気で使おうと思ったのはこのLTを聞いて、いくつか質問したときです （RakeやGitでも使える、的な話） あと、WEB+DB PRESSでも（テスト関連ツールとして）紹介されていました WEB+DB PRESS Vol.61 作者: 西岡祐弥,濱田章吾,浦嶌啓太,高橋健一,柴田博志,井上誠一郎,大谷弘喜,荻野淳也,原悠,増井俊之,横山彰子,浜本階生,ミック,uupaa,塙与志夫,はまちや2,大沢和宏,中島聡,矢野りん,中島拓,角田直行,WEB+DB PRESS編集部出版
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
どうも皆さんこんにちは、GW返上で頑張る babie でございます。日中にキャッキャウフフ行楽してる奴は殺人光線を浴びて死ぬ。 Rails のインテグレーションテストで一般的となった Capybara ですが、JavaScript のテストには選択肢が色々あります。envjs, selenium, akeity, culerity などなどです。迷いますねー。 ですが、当方、Ruby 1.9.2 p136 on Ruby 1.9 系列ではコンパイルできないので× selenium ―― X ごっそり入れるのイヤなので× akeHTMLUnit が jQuery 1.2 までしか対応してないので× celerity ―― JRuby 専用なので× culerit
よく、ユニットテスト書くときに忘れるのでメモメモ。 Visual Studio 2008からProfessional版に搭載された単体テスト機能ですが 普通にユニットテストを作ると以下のようになります。 テスト対象メソッド public int Sum(int x, int y){ return (x + y); } 自動作成されたテストメソッド /// <summary> ///Sum のテスト ///</summary> [TestMethod()] public void SumTest() { Program target = new Program(); // TODO: 適切な値に初期化してください int x = 0; // TODO: 適切な値に初期化してください int y = 0; // TODO: 適切な値に初期化してください int expected = 0; //
Visual Studio 2008単体テスト機能のすべて：特集：Visual Studio 2008単体テスト機能徹底活用（前編）（1/4 ページ） 連載目次 Visual Studio 2005（以下、VS 2005）では上位エディションであるTeam Developerでのみ利用可能だった単体テスト機能が、Visual Studio 2008（以下、VS 2008）からは、Professional Editionでも利用可能になった。 VS 2008の1機能として導入されるほど単体テストが脚光を浴びるようになったのは、やはりアジャイル開発の普及だろう。アジャイルで開発する場合、単体の品質が非常に重要になる。また、リファクタリングなどで繰り返しテストが必要になるケースが多いため、テストを自動化するという考えが生まれ、単体テストの注目度はさらに増している。 本稿では、このVS 2008
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
