3年前にこんな記事をあげました。 bleis-tift.hatenablog.com 3行でまとめると、 Power Assertはユニットテストのためにほしかったものではない 欲しいのは結果の差分 誰か作って！ というエントリでした。 そしたら id:pocketberserker が作ってくれました！ github.com PowerAssertより強そうな名前でいい感じです。 Power Assertは時代遅れ、今はMuscle Assertだ！的な話かな？— 裸のWPF/MVVMを書く男(マン) (@gab_km) 2016年6月1日 MuscleAssertの使い方 このライブラリは、PersimmonというF#用のテスティングフレームワークを拡張するライブラリとして作られています。 ただ、ざっくり概要をつかむだけであればどちらも知らなくても問題ありません。 このライブラリででき

Jenkinsでは、JUnitのテスト結果からテスト件数や実行時間などを集計することが出来ます。この時、JUnitの実行結果はXML形式のファイルとして出力され、「JUnitのXMLファイル」などと呼ばれています。ところが、このXMLのフォーマットは、JUnitの公式フォーマットではありません。JUnit自体には実行結果をXML形式に出力する機能は実装されていないため、Ant, Maven, Gradleといったビルドツールによって出力されています。恐らくはAntが出力していたJUnitの実行結果のXMLフォーマットに、Eclipseなどの他のツールが対応していき、結果としてデファクトスタンダードとなったと思われます。 Jenkinsでは、デフォルトでJUnitのXMLを集計できるため、他のテストツールを使ってテストを実行した場合にも、JUnitのXML形式に変換すれば、簡単にJenkin

第３回 #渋谷Java の発表資料です。ランダムに振る舞う機能を、どのように JUnit でテストできるようにするかを記載しています。 http://atnd.org/events/42501

リリースされていたので目玉のひとつになりそうな Action 属性についてちょっと調べてみました。というか、公式ページの解説を抄訳しただけともいえますが。 すごく簡単なしくみです。 Action 属性を使うことで、これまで SetUp/TearDown/FixtureSetUp/ FixtureTearDown みたいな属性をつけた上でメソッドとして書いてきた準備とか後始末を、Action クラスにカプセル化して、属性ベースでテストに適用できるようになります。 テストの眼目は当然テストコードにあって、その準備や後始末については、テストの本質ではありません。ただ、どういったコンテキストかでのテストであるかということを示す情報として意味はありますから、完全に隠蔽するのも良くありません。そこで、準備や後始末自体が抽象化され、名前がついた状態で再利用できることはたしかに意味がありそうです。 前述の

ユニットテストなどではテスト対象外の振る舞いをテスト目的に合わせるためにモックやスタブ等を作成することがあります。 .NET開発でこの様なモックやスタブを簡単に作成するフレームワークにMicrosoft ResearchのMolesがあります。 このMolesは以前に紹介したPexにも含まれています。 Molesを使用すれば設計対象範囲外（例えば.NETフレームワークのコアライブラリなど）も含めて、既存のクラスのフィールド（プロパティ）やメソッド単位でデリゲートを使用して振る舞いを置き換えることができます。 例えば public class MolesTest { public DateTime GetTheDate() { Console.WriteLine("OK"); return DateTime.Now; } } このような.NETのコアライブラリのConsoleクラスのWrit

Ryutaro YOSHIBA / Agile Coach, CTO at Attractor Inc. 翻訳者/ Scrum Alliance認定チームコーチ(CTC) /書籍→『SCRUM BOOT CAMP THE BOOK』『プロダクトマネージャーのしごと』『エンジニアリングマネージャーのしごと』『チームトポロジー』『スクラム実践者が知るべき97のこと』『プロダクトマネジメント』『みんなでアジャイル』『レガシーコードからの脱却』『カンバン仕事術』『Effective DevOps』他 ご相談はお気軽に!!

VBAUnitは、Excelアドイン形式のVBA用Unit Testing Frameworkです。 アドインなので、参照するだけで使用できます。 おなじみのRed/Green Barも表示されるGUIインターフェースもあります。

会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識

TestLinkでテスト管理をしてみた経験、他の人から聞いた話から、TestLinkを運用したけど使いこなせない症状にパターンがあるような気がした。 それらをアンチパターンとしてまとめてみた。 【元ネタ】 TestLinkがExcelのテスト仕様書よりも素晴らしい点 TestLinkを運用して気付いたことpart4～TestLinkの概念を再考 TestLinkを運用して気付いたことpart5～TestLinkのテストケースの概念 TestLinkを運用して気付いたことpart6～テスト工程のプロジェクト管理 TestLinkを運用して気付いたことpart7～要件カバレッジは難しい TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス TestLinkを運用して気付いたことpart9～後追いテスト 【公開】脱Excel！ Tes

Exploring the C++ Unit Testing Framework Jungle 2004年時点のC++テストフレームワーク比較記事。理想的なテストフレームワークを求めて、CppUnitとその後継達を比べている。この記事は同じようにC++で何とかPainlessなUnitTestをしたい人々に参照されたようだ。 この記事を書いたNoel Llopisは、その後出てきたUnitTest++に携わっている。本家サイトから書き方の引用。かなり初心者には不親切な例だｗ TESTマクロ一発でテストがかけて超簡単。 #include <UnitTest++.h> TEST(FailSpectacularly) { CHECK(false); } int main() { return UnitTest::RunAllTests(); } FIXTUREサポート Setup/Teardow

ヨシオリX @yoshiori なんか「テストファースト」って言葉に2種類の使われ方があって、混乱するなぁ…… テスト手法のテストファーストと、開発手法のテストファーストはわけるべきだよなぁ 2010-02-15 00:43:52 ヨシオリX @yoshiori 「TDD はテスト計画をせずにテストしてしまうから……」とか「品質管理のためには……」とか言われるとなぁ TDD はあくまで"開発"手法であって、テスト手法では無いんだよね。もう、TDDで品質があがるって啓蒙するの止めちゃえば、いっそ変な誤解が広がらないんじゃないかなぁ。 2010-02-15 00:47:13

Tech Ed 2009 で、「Moq」というライブラリの存在を知りました。Moq はモックを使った単体テストを記述するためのライブラリです。 moq - The simplest mocking library for .NET and Silverlight - Google Project Hosting Moq の特徴は、モックの振る舞いをラムダ式で指定できること。ラムダ式で指定できるので、Visual Studio のインテリセンスの恩恵が受けれます。 Moq を使ったテストコードは次の通り。 // あいさつインタフェース // Moq を使って、このインタフェースを実装するモックを作成する public interface IGreeting { string Greet(string name); } // モックを生成 Mock<IGreeting> mock = new

NUnit 2.5 RC - ZOETROPEの日記 これみてもらえればもうほとんど言うことって残ってないんですが・・・ 一応、ちょっと補足的な情報を。 TestCase 元エントリでは引数が 3 つとなってますけど、3 つ以上も可能でした。 [TestFixture] public class AttributeTestSample { [TestCase(1, 2, 3, 6)] [TestCase(10, 20, 30, 60)] [TestCase(10, 10, 10, 30)] public void TestCaseSample(int x, int y, int z, int expected) { Assert.That(x + y + z, Is.EqualTo(expected)); } } TestCaseSource との使い分けの指針としては、 コンパイル時定数