JUnit4のassertThat()って便利なの？JUnit4ではhamcrestライブラリーが統合されており、伝統的なassertEquals()を使った比較以外に汎用的なassertThat()が使えます。これを使うとより英語的に自然に読めるアサーションを記述できるとされています。しかし、Classクラス同士の比較ができないといった問題もありますし、そもそも日本人にとって便利なのかという疑問もわきます。
テストをどこまで書くか - はこべにっき ♨
CROSS2014で以下の2つのセッションにお招きいただきお話をさせていただいた。ありがとうございました。 http://www.cross-party.com/programs/testcidevops/ はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey 2014/1/17 #cross2014 現場に聞く！テスト/CI/DevOps、実際のところどうなの - Togetterまとめ http://www.cross-party.com/programs/butsukari/ 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetterまとめ セッション中はもちろん、その後の懇親会でもいろいろな方におはなしを伺えてかなり勉強になった。テストやコードレビ
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
privateメソッドのテストについて
瀬良 @shela_ @irof publicからprivateを含めて検証するのと、private単体だけで検証するのであれば、先にprivate単体で検証しておいた方が安心感があると思う 2012-08-25 16:38:24
状態のあるコードに対するテストの自動生成 - 西尾泰和のはてなダイアリー
BLUE*アルゴリズムを実装してみたので、せっかくだからテストの自動生成をやってみた。 今回テスト対象にするコードの仕様は 開く、閉じる、書き込む、の3つの操作ができる 開いてないのに書き込んだり閉じたりしたらエラーになる というもの そしてこちらがそれの「バグのある実装」： class Target(object): # bad impl. def __init__(self): self.opened = False self.closed = False def open(self): self.opened = True def write(self): if not self.opened: raise RuntimeError if self.closed: raise RuntimeError def close(self): if not self.opened: rais
「同じコード」の同じって何さ - TAPのススメ : 404 Blog Not Found
2008年03月27日03:00 カテゴリArtLightweight Languages 「同じコード」の同じって何さ - TAPのススメ 問題は、この「同じコード」の定義。 「誰が書いても同じコード」は大事なことなのか - ひがやすを blog でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。同じ「書き方」をしなければならないのか? 結果が「同じ」ならいいのか? もし後者だとしたら、実は 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 すら必
新人注目！ テストを極める最初の一歩 記事一覧 | gihyo.jp
第3回コピー＆ペーストでテスト仕様書を作っていませんか？ 鈴木三紀夫，池田暁 2008-07-14
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
iutest プロジェクト日本語トップページ - OSDN
googletest - Google C++ Testing Framework - Google Project Hosting