競技プログラミングでは、提出したプログラムが誤答(WA)だった場合に「どのような入力について」答えを間違えたのか(参加者には)分からないことが多いです。 こういう場合はエスパーするなり眼力でソースコードをぐっと睨んだりするとバグが発見できる場合もありますが、初心者にはそういうのは難しいでしょう。 この記事では、HaskellのQuickCheckというライブラリーを使って、「ランダムにテストケースを生成して素朴な解と一致するか」を自動で検証させます。QuickCheckはテストに失敗した場合に「どういう入力例に対して失敗したか」も教えてくれるので、デバッグにも役立ちます。 この記事は筆者が先日YouTubeに上げた動画を文章で書き直したものです。動画で触れられなかった・触れるのを忘れていた補足説明みたいなものも若干含んでいます。この記事と動画、両方見ていただけると嬉しいです。 今回取り上げ
I have just released two libraries to enhance QuickCheck for testing higher-order properties: quickcheck-higherorder and test-fun. This is a summary of their purpose and main features. For more details, refer to the README and the implementations of the respective packages. Context This project started from experiments to design laws for the mtl library. What makes a good law? I still don’t know t
I have been working on property testing for years now. My current conclusion is that property testing still has so much uncovered potential that with just some more effort, it can become an even greater tool for software development than it already is today. The concept is relatively young and the design space relatively unexplored. This post seeks to provide an overview of the different approache
テストには常にある種の不安が残ります。このテストは果たしてすべての場合に妥当だと言えるのか? 何か見落としてはいないか? その見落としは致命的なものではないか? Haskellの静的な型検査をすり抜けてくるバグに対処するには,実際にプログラムを動作させ,HUnitなどで動的なテストを行います。では,動的なテストをすり抜けるバグにはどう対処すればいいでしょうか? 一番単純な対策は,テスト項目数を増やすことです。たいていの場合,テスト項目は「その型の取りうる値を想像し,その例に対してきちんと動作するかどうかを確かめる」という形で記述します。単純に考えるなら,テスト項目が増えれば増えるほどテストの正確さは増していくはずです。 しかし,個々の値に対してテストを記述していくのは手間のかかる作業です。テストを行うべき値の集合に対してテストを行うツールが欲しくなりますね。それが「データ駆動型のテスト・ツ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く