QuickCheckテストの信頼度チェック - taketoncheir.log
この記事はHaskell Advent Calendar 2012用の記事です。 今年はテストに関わる記事が多いように思います。 継続的な開発を行う上でテストは必要なので、テスト手法をキャッチアップしたいと思っていたところでした。まるで渡りに船、いや、ほむらにまどかです。 （追記） QuickCheckで自分で定義したデータ型に対してテストを書きたい場合はこちら QuickCheckでデータがランダムに生成される仕組みについてはこちら QuickCheck テストを書く際、QuickCheckで性質のチェックも行うと思います。 QuickCheckは、 "QuickCheck is property-based tool for random testing." (Arts, 2005) pdf download なるものです。 テスト対象の関数が満たすべき性質を記述し、QuickChec
QuickCheckのコード読んでみた - taketoncheir.log
QuickCheckでtestデータがgenerateされる仕組み 実際に定義したデータ型に対してデータを生成する方法はこちら ここではQuickCheckのソースコードについて記します。 実際に読み取った順に書いているので分かりにくいです、すいませんm(__)m 登場人物 class Testable : ユーザが定義した、Boolを返すプロパティ quickCheck : ユーザが定義したTestableを受け取り、試行ごとにランダム値を生成しながらStateを引き回していくテスト管理部分 newtype Gen a : StdGenとサイズ上限値を取って生成されたデータを返す。サイズ上限値は例えばリスト型のデータ生成時に生成するlengthの上限値xとなり、lengthは1~xの中からランダムな値が選ばれる。 class Arbitrary a : テストデータ生成部分 type P
たのしいHaskellのツールチェインとC++ - 純粋関数空間
というタイトルで、先日、社内の公開セミナーで話しました。 発表資料はこちら。 Haskellのテストフレームワークとベンチマークフレームワークがよくできているので、 これをC++でも使えるんじゃないかという内容です。 概要 背景として、QuickCheck をもっと多くの人に知って/使って貰いたいというのがあります。 QuickCheckは、普段から使っている人間からすると、よくいろいろなバグを拾ってくれるとても便利なものなのですが、 残念ながら普段開発に利用しているC++には相当のもので完成度の高いものが見当たりません。 だからといって、そこから作るためにC++のテンプレートをいじくりまわすには、私はもう老いてしまいました （与えられた関数にランダムな入力を与えるだけなら簡単なのですが、ジェネレータを自由にいじれる機能がやはり欲しいところで）。 そう思った時に、FFIを使えてQuickC
QuickCheckのArbitraryのやつ - はわわーっ
QuickCheckでテストに使われるランダムな値の設定とか。 QuickCheckを使うには Test.QuickCheck モジュールが必要。 参考: 本物のプログラマはHaskellを使う - 第17回 QuickCheckでデータ駆動型テストを行う：ITpro 本物のプログラマはHaskellを使う - 第18回 QuickCheckを使ってできることとできないこと：ITpro ランダムに値を生成するのに arbitrary を使って 生成される値をみるには sample を使う。 >>> sample (arbitrary :: Gen Int) -1 0 -1 0 13 -6 -71 105 535 -259 167 >>> sample (arbitrary :: Gen [Int]) [] [2] [4,4] [-5,0] [-17,-20,31,2] [-3,48,-31
第17回 QuickCheckでデータ駆動型テストを行う
テストには常にある種の不安が残ります。このテストは果たしてすべての場合に妥当だと言えるのか？ 何か見落としてはいないか？ その見落としは致命的なものではないか？ Haskellの静的な型検査をすり抜けてくるバグに対処するには，実際にプログラムを動作させ，HUnitなどで動的なテストを行います。では，動的なテストをすり抜けるバグにはどう対処すればいいでしょうか？ 一番単純な対策は，テスト項目数を増やすことです。たいていの場合，テスト項目は「その型の取りうる値を想像し，その例に対してきちんと動作するかどうかを確かめる」という形で記述します。単純に考えるなら，テスト項目が増えれば増えるほどテストの正確さは増していくはずです。 しかし，個々の値に対してテストを記述していくのは手間のかかる作業です。テストを行うべき値の集合に対してテストを行うツールが欲しくなりますね。それが「データ駆動型のテスト・ツ
bdd.gby
1 Haskell Behavior Driven Development 2012.5.27 @kazu_yamamoto 2 Haskell 4 Mew Firemacs Mighty ghc-mod 3 Ruby/Java HackageDB 4 Haskeller 5 Haskeller 6 Q) Haskeller A) 7 8 Haskeller Haskell 9 10 11 Haskell 12 Haskell Haskell 13 14 Haskell 15 Haskell 16 Haskell 17 \^^/ 18 19 20 Haskeller HUnit QuickCheck 21 QuickCheck prop_doubleSort :: [Int] -> Bool prop_doubleSort xs = sort xs == sort (sort xs) >
BDD on Haskell チュートリアル その2 : QuickCheck でランダムテスト
新年のご挨拶あけましておめでとうございます． 2012年は Schemer, Haskeller にとって飛躍の年でありますよう心から願う所存であります． デザインについてはあと最終勧告まで2年を切った HTML 5 がそびえたつクソにならない事を切に祈り，ユーザビリティ，アクセシビリティ，ユースケース，UX をガン無視した「CSS3だけで出来たなんちゃらかんちゃら」「美麗なビジュアルエフェクトを実現する jQuery プラグイン」で衆目を集めてなんちゃってクリエイティブ気分を味わってる人たちが滅亡してくれる事を期待しています 前回までのエントリーBDD on Haskell の為のディレクトリ構成を考える BDD on Haskell チュートリアル その0 BDD on Haskell チュートリアル その1 : HUnit で TDD を 今回は QuickCheck を使ってランダ
少しはテストを楽しくやる(QuickCheck) - yunomuのブログ
テストって別にやりたくないわけじゃないっていうかやりたいんですけど、なんかつい後回しになってしまうというか。 でも例えば外部システムとの連携部分だったりすると私は割と真面目にテストを書くんですが、普段はなんかなんとなく面倒臭い。面倒くさいと面倒くさくないの境界線は何なんだ。 外部システム連携みたいな入出力系のテストがそれほど苦じゃないのは、どっちにしろ動作確認で動かすからなんですよね。 一方でそれ以外の部分、いわゆる計算というか、モジュール間のデータのやり取りだったりデータ変換だったりとか、そういう部分のテストがなんで面倒くさいかといったら、それは足し算をテストする時の事を考えるとだいたい想像つくと思いますけど、 @Test void testPlus() { assertEqual(plus(1, 1), 2); assertEqual(plus(1, -1), 0); assertEq
Haskell演習の草稿 - あどけない話
プログラミングの経験はあるが、Haskell は使ったことがない人に、2時間ぐらいで Haskell のよさを教える演習のネタを考える。 Haskell の代表的な利点といえば、 型による厳密なプログラミング QuickCheck によるテストケースの自動生成 Persec によるパーサーの作成 だ。今回は、パーサーの作成は諦めて、上2つについて教えてみる。 リストの探索プログラム まず、連想リストを探索するプログラムを書く。標準では lookup という関数が用意されているが、これを search という名前で再発明する。オーダーは O(n)。 まず、型を考える。 search :: Eq k => k -> [(k,v)] -> Maybe v search = undefined 次に、実装を考える。 search :: Eq k => k -> [(k,v)] -> Maybe v
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
