テストケース自動生成器をつくる
はじめに プログラムから自動的にテストケースを生成するテストケース生成器を作ってみます． プログラミング言語は Scheme, 処理系は Gauche を使います。 プログラムの構文 プログラムの構文は次のようにします。S式です。 変数は整数型だけとします。 文は5種類用意します： skip (set! 変数 式) (if 条件 文 文) (while 条件 文) (block 文 ...) 式は前置記法で、次の演算子を用意します： and or not = > < >= <= + - div しくみ 基本的な考え方： if 文の条件に着目する プログラムからテストケースを作るときは，if 文に着目して，その条件が成り立つ場合と成り立たない場合をそれぞれテストケースとします． この条件を，プログラムの入口の方に向かって変換していって，プログラムの先頭で成り立つべき条件が得られれば，それがテ
「アプリケーションが壊れているのに検知できないテストコード」を書かないようにするための、べからず集 - Qiita
はじめに テストコードを書くことは重要です。 テストコードがないアプリケーションよりもテストコードがあるアプリケーションの方が望ましいことは間違いありません。 ですが、テストコードも書き方を間違えると、アプリケーションが壊れているのに正しく検知できないテストを書いてしまう可能性があります。 この記事ではそんな「アプリケーションが壊れているのに正しく検知できないテスト」のコード例を「〜するべからず（〜してはいけない）」の形式で紹介し、その修正方法を説明していきます。 サンプルコードはRSpecで書いてます（でも他の言語でも考え方は同じはず） サンプルコードはRailsアプリケーションをRSpecでテストする場合を想定したものになっていますが、基本的な考え方自体は他の言語やテスティングフレームワークでも適用可能なはずです。 RSpecのイロハについて先に学んでおきたいかたは「使えるRSpec入
プログラマーテストの原則 by Kent Beck
チョコレート対バニラTDD対BDD。このテストツール対あのテストツール。テストビフォー対テストアフター対これは動くから俺を信じろ。ある時期から、こうした詳細に関する議論には飽きてしまった。もっと原則について議論したい。 詳細に関する議論はなかなか結論に至らずに、話が行ったり来たりする。チョコレート対バニラ。チョコレート。バニラ。チョコレート。バニラ。 詳細の議論に負けを認めさせられるようなことがあっても、その譲歩は絶対的なものではない。私の状況がチョコレートを勧めているのに、私にバニラを食べさせてくれと言えるだろうか？ これでは埒が明かない。 原則一方、原則は議論を生み出す基盤になる。原則には賛成しても状況が違っているのなら、答えは違ってくるかもしれないが、そこで論争になることはない。原則が、異なる状況における異なる答えを生み出したのである。 詳細で論争するよりも、原則で論争したほうが生産
複数条件の組み合わせによるテストケース数爆発と戦うPairwise(ペアワイズ)法とそれを支えるツール「PICT」 | DevelopersIO
ペアワイズ法を使うことで、効率的にテストケースを絞り込めることがわかったかと思います。 --- 2019/10/31 追記 --- どうしてテストケースを絞り込んでも大丈夫なのか？という意見がSNSやはてブのコメントで見受けられたので、フォローアップエントリを書きました。こちらも合わせてご覧ください。 ペアワイズ法は本当に有効なのか？組み合わせテスト技法と上手に付き合う方法 ｜ DevelopersIO ペアワイズ法を支えるツール「PICT」 ペアワイズ法が有効なことはわかりましたが、この組み合わせをどうやって作れば良いでしょうか？条件の数が少なければ前述のように手作業でもやれないことはありませんが、現実の問題はもっと複雑ですので、到底無理でしょう。 そこで役に立つのが、ペアワイズ法のテストケースを生成してくれるツール「PICT」です。 microsoft/pict: Pairwise I
テストのめどい話
最初にめどい言い訳をせねばならぬ俺は江島氏ともきょん氏とも面識はないですが、お二人ともが俺のことを知ってることを俺も知ってる程度には狭い業界であり。どちらかに肩入れしたいわけではないです。喧嘩したいわけでもないです。普段あまりここでは言及しないですが俺は今の仕事としてはテストを書いたりテストを実施したりする係をしてノリクチをしのいでおり、いわばテストは本業ですので、テストに言及することは今現在の同僚に対して意図しない受け取られ方をする可能性があるので困るので、それもあって普段はここではあまりテストの話はしないわけだが、だからと言って沈黙を破ってテストの話をするのが同僚に対して含みがあるというわけでもないです。とはいえ俺は大学等で真面目にソフトウエア工学の講義を受講したことがなく、経験と勘と昔取った杵柄だけで食ってるので、そういう意味では若干の後ろめたい気持ちもある。で、テストって何なん俺が
Go の Test に対する考え方 - Qiita
この記事は Go Advent Calendar 2013 の 9 日目の投稿です。 今回は、 Go の testing というパッケージの使い方を解説しようと思ったのですが、 それだとつまらなすぎるので、合わせて Go が test というか assert についてどういうスタンスをとっているかを書いてみます。 Go でテスト さて、「テストのないコードはレガシーコード」などと言われて久しく、様々な言語が test (主に Unittest) について言語レベルでサポートしたり、デファクトなライブラリが確立したりといった状況が、今日では至って普通のこととなっています。 そんな言語や環境で、息をするようにテストを書いてきたみなさんが、はじめて Go でコードを書く時に見るべきは testing パッケージです。 http://golang.org/pkg/testing/ 命名規則 では、
ユニットテスト改善ガイド | DevelopersIO
先日、日本Javaユーザグループ（JJUG）主催のJJUG CCC 2013 Fallで、「ユニットテスト改善ガイド」というタイトルで登壇してきました。自分の経験を元に、ユニットテストをチームや組織へ導入する時に起こりえる問題とその解決のヒントに関するセッションです。本エントリーではそのセッションの内容を再構成して公開します。 はじめに 近年のシステム開発では、ユニットテストや継続的インテグレーション（以下、CI）の導入は必要不可欠と考えられています。とはいえ、どんな組織（チーム）でも簡単に導入できているわけではありません。特に、大きな組織や古くからの慣習を残している組織では導入したくとも中々進まないと感じているところが多いのではないでしょうか？。 私は、これまでに多くの開発現場でユニットテストやCIの導入について推進してきました。成功したケースもあれば失敗したケースもあります。そして、失
jstest
The cross-platform JavaScript test framework jstest is a testing framework for JavaScript that’s designed to run on any platform with minimal effort. It provides a familiar RSpec-style API for organising tests that can run on the following platforms: Web browsers: Chrome, Firefox, Internet Explorer, Opera, Safari Headless browsers: PhantomJS, SlimerJS Server-side platforms: Node.js, Narwhal, Ringo
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey
Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので読み返してみました。 Testing like the TSA by David of 37signals（TSAはTSAロックのTSAですね。RailsConf行く時に買った） 予想通り、DHHはなんでもかんでもテストを書くということに対してはだいぶ批判的なスタンス。 曰く、テストを書くということの裏側には、テストを書く時間、テストをアップデートする時間、テストコードを読んで理解する時間といったコストが発生しているので、テストを書くことによって得られるメリット（回避できる問題）とのバランスをよく考える必要がある、と。 議論を呼ぶことは承知のうえでDHHが提案する「Railsアプリのテストにおいて、やってはいけない7つのこと」は以下の通り。 100%の
テストを書かないと品質はやっぱり下がる - Be Happyman!!
私は今だにxUnitに代表される自動テストツールの効果が今ひとつ腑に落ちていなかったのですが、プロジェクトメンバーがその効果を調査・分析・見える化してくれたおかげですっきりしました。私の中だけに留めておくのはもったいないのでエッセンスを公開します。*1 対象プロジェクトに関する情報は以下の通りです。 業務系 画面数は60程度 帳票数は15程度 Java(Seasar2/S2Struts/S2Dao),Web系 クラス数は750程度 開発期間は約半年 最終的には総じて高い品質を実現した テストツールとしては、JUnit/EZmock/S2TestCaseを使っていて、それぞれ対象となるレイヤは、Actionクラス/Serviceクラス/Daoクラスです。画面のテストにはSeleniumも使いましたが、今回の調査の対象外としています。 目的 テストで重要なのは、要はそれぞれの工程で適切な粒度・
assertEqualsよりassertThatが好きなわけ - 日々常々
assertEqualsよりassertThatが好きなのは、Matcherもあるけど、引数の順番に悩まないからです。英語として云々なんてどうでもいい。。。。 2012-07-13 00:07:14 via YoruFukurou 元ネタ*1は「xUnitよりRSpecがいいとか言ってたひとは英文ぽいのがいいとか言ってたけどさー」みたいな感じでしたが、xUnitであるところのJUnitでも最近は assertThat なんてもんが入って英文ぽさを売りにすることもあったりなかったり。 ツイートでも言ってる通り、英文ぽさなんてどうでもいいと思ってます。可読性は大事だけど、読めるならそれ以上は要らない派。ならば決め手は何だ。書きやすさと、エラー時の表示です。 assertEqualsのばあい こんな感じに書きますね。短い。書く量が少ないのは良いです。でも１番目と２番目どっちがどっちだったか。 a
JaSST10周年記念誌
JaSST開催10周年を記念して、発行したものです。JaSSTにご協力いただいた著名な方々のメッセージあり、新進気鋭の若者の元気な文あり。各JaSSTの様子なども実行委員の言葉を通して語られています。 ※付録としてソフトウェアテスト年表PDFのダウンロードつきです(zip圧縮ファイルのダウンロード)。 書誌情報 著者: ソフトウェアテストシンポジウム実行委員会 発行日: 2012-01-25 最終更新日: 2012-01-25 バージョン: 1.0.0 ページ数: 248ページ(A5PDF版換算) 対応フォーマット: EPUB, PDF, ZIP 出版社: 達人出版会 目次 第1章 基調講演者・招待講演者からのメッセージ Five Trends Affecting Testing, Five Years On and Beyond： Rex Black Software developme
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発者向けのテストの本いろいろ
組織にテストを書く文化を根付かせる戦略と戦術（2019夏版） / Strategy and Tactics of Building Automated Testing Culture into Organization 2019 Summer Edition
なぜテストを書くの？（または書かないの？） 〜テストコードの7つの役割〜 / #tamarubykaigi01
Bitbucket | Git solution for teams using Jira