Choosing properties for property-based testing | F# for fun and profit
Or, I want to use PBT, but I can never think of any properties to use UPDATE: I did a talk on property-based testing based on these posts. Slides and video here. In the previous two posts, I described the basics of property-based testing, and showed how it can save a lot of time by generating random tests. But here’s a common problem. Everyone who sees a property-based testing tool like FsCheck or
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
Mistaeks I Hav Made: Exploring Test-Driven Development with QuickCheck
Good judgement is the result of experience ... Experience is the result of bad judgement. — Fred Brooks I've been wondering how property-based testing tools, such as QuickCheck affects the Test-Driven Development process and the designs that the process drives out. When TDD was introduced in the late 1990s, it was described in terms of example-based testing tools, such as the xUnit family of frame
Inemuri nezumi diary(2006-09-06)
_ RushCheck - a lightweight random testing tool for Ruby Ruby のランダムテストライブラリ RushCheck を公開している。これは3年前からつくり出したもので、PC で眠っていたものを今年の夏休みに公開したものである。Haskell の QuickCheck を Ruby でも使いたいなあと思ったのがきっかけであった。 ランダムテストというのはテスト手法のひとつである。テストケースに入力するデータをテストインスタンスと言うことにしよう。このとき、テストインスタンスを自動生成するというのがランダムテストの特徴である。たとえば文字列を入力とするテストならば、ランダムテストではその入力文字列をランダムに生成する。いくつもの異なった入力をランダムに生成して、同じテストケースを自動的に何度も実行するというテストの考え方である。 _ ラン
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 を使ってランダ
第17回 QuickCheckでデータ駆動型テストを行う
テストには常にある種の不安が残ります。このテストは果たしてすべての場合に妥当だと言えるのか？ 何か見落としてはいないか？ その見落としは致命的なものではないか？ Haskellの静的な型検査をすり抜けてくるバグに対処するには，実際にプログラムを動作させ，HUnitなどで動的なテストを行います。では，動的なテストをすり抜けるバグにはどう対処すればいいでしょうか？ 一番単純な対策は，テスト項目数を増やすことです。たいていの場合，テスト項目は「その型の取りうる値を想像し，その例に対してきちんと動作するかどうかを確かめる」という形で記述します。単純に考えるなら，テスト項目が増えれば増えるほどテストの正確さは増していくはずです。 しかし，個々の値に対してテストを記述していくのは手間のかかる作業です。テストを行うべき値の集合に対してテストを行うツールが欲しくなりますね。それが「データ駆動型のテスト・ツ
Redirecting...
Redirecting... Click here if you are not redirected.
たのしいHaskellのツールチェインとC++ - 純粋関数空間
というタイトルで、先日、社内の公開セミナーで話しました。 発表資料はこちら。 Haskellのテストフレームワークとベンチマークフレームワークがよくできているので、 これをC++でも使えるんじゃないかという内容です。 概要 背景として、QuickCheck をもっと多くの人に知って/使って貰いたいというのがあります。 QuickCheckは、普段から使っている人間からすると、よくいろいろなバグを拾ってくれるとても便利なものなのですが、 残念ながら普段開発に利用しているC++には相当のもので完成度の高いものが見当たりません。 だからといって、そこから作るためにC++のテンプレートをいじくりまわすには、私はもう老いてしまいました （与えられた関数にランダムな入力を与えるだけなら簡単なのですが、ジェネレータを自由にいじれる機能がやはり欲しいところで）。 そう思った時に、FFIを使えてQuickC
QuickCheck使ってC++のテストも有効である可能性
理解できなかったけれど何か重要な事を言っているような気がしたのでまとめておきます．「誰でも編集可」にしておきます．関連ツイートなど自由に追加して下さい．
少しはテストを楽しくやる(QuickCheck) - yunomuのブログ
テストって別にやりたくないわけじゃないっていうかやりたいんですけど、なんかつい後回しになってしまうというか。 でも例えば外部システムとの連携部分だったりすると私は割と真面目にテストを書くんですが、普段はなんかなんとなく面倒臭い。面倒くさいと面倒くさくないの境界線は何なんだ。 外部システム連携みたいな入出力系のテストがそれほど苦じゃないのは、どっちにしろ動作確認で動かすからなんですよね。 一方でそれ以外の部分、いわゆる計算というか、モジュール間のデータのやり取りだったりデータ変換だったりとか、そういう部分のテストがなんで面倒くさいかといったら、それは足し算をテストする時の事を考えるとだいたい想像つくと思いますけど、 @Test void testPlus() { assertEqual(plus(1, 1), 2); assertEqual(plus(1, -1), 0); assertEq
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - HypothesisWorks/hypothesis: Hypothesis is a powerful, flexible, and easy to use library for property-based testing.
GitHub - thejohnfreeman/autocheck: Header-only C++17 library for property-based testing.