本日大江戸*1で行われた大江戸Ruby会議01で、高速なテストサイクルを回すにはという内容で発表してきました。 大江戸Ruby会議01 高速なテストサイクルを回すには View more presentations from hotchpotch テストを速くするには二パターンあり、一つは単体実行時の速度・フィードバックの高速化、もう一つはすべてのテスト実行時の高速化があると思っていて、それらについての話です。ぎゅっとまとめると、前半の単体実行時の速度・フィードバック高速化には spork / prefetch-rspec / autotest / watchr を使おうという話と、後半は REE / parallel_tests による高速化・並列実行、remote spec によるリモートマシンでの分散テストについての話です。 特にオレオレプロジェクトの prefetch-rspec
JUnit を知れば知るほどおもしろくなってきた♪JUnit 4.4 の機能について調べても日本語の情報があんまりなかったから,メモとして書いとこう. さて,まずはassertThatについて.このメソッドの説明は,実際の使用例を見てもらった方がわかりやすいと思うので,まず次の使用例をみてみて.(JUnit 4.4 Release Notesより.) assertThat(x, is(3)); assertThat(x, is(not(4))); assertThat(responseString, either(containsString("color")).or(containsString("colour"))); assertThat(myList, hasItem("3")); 深読みせずに読むと,上から「x は3.」「x は4ではない.」「responseString は,c
みなさんこんにちは。@ryuzeeです。 SlideShareでテスト自動化に関する良いスライドをみつけたのでご紹介します。 Agile Toolkit http://www.slideshare.net/nverdo/agile-toolkit-mo-conf 参考になる部分は以下の3スライドでしょう。順に説明していきます。 手動テストのコストプロジェクトの初期は以下のような状況です。 テストする項目は少ない手動でテストを完了するのも簡単まだプロダクションでもないし、問題があって影響を受けるのは限定された人だけしかし時間がたつにつれて 手動でのテストにはとても多くの時間がかかるようになる製品が出荷されてしまうと、バグによってとても多くの人が影響を受けることになってしまうという状況に変わっていきます。 右のグラフは手動でテストを行った場合のテスト時間の推移を示していますが、見て分かる通り、
ビューティフルテスティング ソフトウェアテストの美しい実践 Tim Riley (編集)、Adam Goucher (編集) 大西建児(監訳・翻訳)、 児島修 (翻訳) オライリージャパン 2010年10月 ISBN-10: 4873114748 ISBN-13: 978-4873114743 3360円(税込) ■テストにおける永遠のテーマから、最新テスト手法まで 美しいテストとは何か? 上記の問いについて、テストのプロフェッショナルたちが経験に基づいて語ったものを集めたエッセイ集――それが本書『ビューティフルテスティング』です。 バグ管理やテストの自動化といった「テストにおける永遠のテーマ」から、ファズテスティングやテスト駆動型開発、アジャイル・テスティングといった、日本でも注目を集め始めた新しいテスト手法の紹介までと幅広く、まさにアメリカのテストの「今」がここにあると言っても過言では
『るびま』は、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 直
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、10回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ!というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
ちょっと Excel VBA でユニットテストしたくなったので、どんなツール/ライブラリがあるか調べてみました。 (2014/12/10 追記) 以下のページのほうが情報が多い&新しいので、こちらを見ていただいたほうがよさそうです。 Coding/VBA/ユニットテスト - ClockAhead 記憶の欠片 (2014/12/10 追記ここまで) VBAUnit Vba Unit VBAUnit | Download VBAUnit software for free at SourceForge.net xUnit っぽく作ってあるらしいです。 問題はプロジェクトにテスト用のクラスを大量に読み込まないといけないこと。 こんな感じで、実際にテストしたいクラスがどこにいるかわからなくなってしまいそうです。 また、VB Lite Unit で指摘されているように、テスト対象のメソッドを列記する
テストを書いているとモックオブジェクトを使う機会が多いと思います。そのモックオブジェクトは自前で作るよりは、JMockやMockito*1などのフレームワークを利用した方が楽でしょう。 今回は機能的に、ほぼ最強と思われるJMockitを紹介します。 これが、他のモックフレームワークとの機能比較です。 MockingToolkitComparisonMatrix - jmockit - A feature matrix comparing several mocking toolkits. - Project Hosting on Google Code 機能が多ければ使いやすいか。そんなことはないと思います。しかし、これは使いやすいかもと周りの人からお勧めがあったので、実際に使ってどんなところが使えるのか検証してみたので、書いてみます。あと、最後にScalaで使えるか試してみました。 あ、
グーグルは検索エンジンだけではなく、メールソフトのGmail、オフィス系ソフトのGoogle Apps、WebブラウザのChromeやOSのAndroidなど、さまざまな種類と規模のソフトウェアを開発しています。 それらはどのようにテストされ品質管理されているのでしょうか? グーグルのブログGoogle Testing Blogに、Test Engineering DirectorのJames A Whittaker氏による「How Google Tests Software」がポストされ、その概要を伝えています。 3つのチームからなるEngineering Productivity Whittaker氏はまず、グーグルにはテストの専門部隊はいないのだ、という組織構造の説明から始めます。 There isn't an actual testing organization at Googl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く