がくり（ソフトウェア関連垢） on Twitter: "昔、Googleのテスト自動化マネージャみたいな人が、日本に招待されて講演後、 日本人「コスパ悪いのをどう解決してますか？」 Google「解決していないです」 日本人「え！？」 Google「？」 日本人「コスパ・・・」 Goo… https://t.co/mWGWIQ7H9p"昔、Googleのテスト自動化マネージャみたいな人が、日本に招待されて講演後、 日本人「コスパ悪いのをどう解決してますか？」 Google「解決していないです」 日本人「え！？」 Google「？」 日本人「コスパ・・・」 Goo… https://t.co/mWGWIQ7H9p
Android/iOSアプリのテストの区分戦略 - クックパッド開発者ブログ
技術部の松尾(@Kazu_cocoa)です。 クックパッドのモバイルアプリ開発では、どのようなテストを書き、どのようなタイミングで、どのようなテストを実施するか？に関してエンジニア各位が意識を合わせるためにテストサイズを定義し運用してきました。ここでは、そんなテストサイズに関して簡単ですがまとめておこうと思います。 テストサイズとは ソフトウェアテストに関わったことがある方なら テストレベル という言葉には出会ったことがあるかと思います。JSTQBでは、このテストレベルは"管理していくテストの活動のグループ"と定義しています*1。 そうでない方も、俗に言う単体テスト/統合テストなど聞いたことがあるかと思いますが、その区分がここで示しているテストレベルとなります。 一方、このテストレベルはV字型と言われる開発工程と合わせて世の中で広く使われているため、社内における共通認識を構築するにあたり個
プログラムに証明が付く日 | RANDMAX
この記事は「Theorem Prover Advent Calendar 2013」6日目の記事です。 http://qiita.com/advent-calendar/2013/theorem_prover 神田「野らぼー」にて、地下の薄暗い店内で… 「そう言えばこないだ隣で起こってたポインタオーバーラン、対応大変そうだったですけどちゃんと家に帰れてたんでしょうかね、新婚なのに…」 「ヌルポとかポインタオーバーランとか、どうして無くならないんだろうね。その時はみんな手を抜いてるつもりなんて毛頭なくて、一生懸命考えて大丈夫だと思ってるはずなんだけどね。レビューもして、それでも起こった後でみんなでソース見てみると、なんで気づかなかったんだよ！ってことになる。」 「人間って、そういうの苦手なんでしょうねきっと。ほら、『何かほかにありませんか』って聞かれても出てこないじゃないですか。静的な解析っ
ユニットテスト改善ガイド | DevelopersIO
先日、日本Javaユーザグループ（JJUG）主催のJJUG CCC 2013 Fallで、「ユニットテスト改善ガイド」というタイトルで登壇してきました。自分の経験を元に、ユニットテストをチームや組織へ導入する時に起こりえる問題とその解決のヒントに関するセッションです。本エントリーではそのセッションの内容を再構成して公開します。 はじめに 近年のシステム開発では、ユニットテストや継続的インテグレーション（以下、CI）の導入は必要不可欠と考えられています。とはいえ、どんな組織（チーム）でも簡単に導入できているわけではありません。特に、大きな組織や古くからの慣習を残している組織では導入したくとも中々進まないと感じているところが多いのではないでしょうか？。 私は、これまでに多くの開発現場でユニットテストやCIの導入について推進してきました。成功したケースもあれば失敗したケースもあります。そして、失
Haskellの単体テスト最前線 - あどけない話
この記事の最新版は、githubで管理されています。 これはHaskell Advent Calendar 2012の5日目の記事です。 Haskellで作成したパッケージに対して、単体テストを書くための最新情報をお届けします。 要約 要点は4つです。 利用者に見せたい振る舞いは、doctest で書く 利用者に見せたくない振る舞いは、hspec で書く テストを自動化するフレームワークとしては Cabal を使う doctest でも hspec でも、純粋なコードに対しては、できるだけ QuickCheck などの性質テストを書く この記事で一番伝えたいのは、3) です。例題としては、Base64 という符号化を取り上げます。Base64 は知っていると仮定して話を進めますので、知らない人はあらかじめ Wikipedia の Base64 の説明でも読んで下さい。 この記事で利用するコ
Test Sizes
Small tests should be isolated from each other, but this constraint gets in a way of medium and large tests (especially for web testing). Take a look at what users are doing with Selenium + TestNG. Also, dependencies and high parallelism are not mutually exclusive, it's unfortunate that this rumor is still around. Here is why: http://beust.com/weblog/2009/11/28/hard-core-multicore-with-testng/ Rep
BDD on Haskell の為のディレクトリ構成を考える
ひさしぶりの Haskell ネタ 2011/12/13 追記下の例で app.cabal の設定や Setup.hs の記述などの情報が古かったので，こちらも一読してください → BDD on Haskell チュートリアル その0 経緯Haskell でそれなりのプログラムを書いてみようとしたので，HUnit や QuickCheck を使って BDD でやろうとしたのだけど，How to write a Haskell program 以上の事を誰も書いてないし，HUnit や QuickCheck の実例を書いた日本語圏のブログ記事も，その単体モジュールのテストのみ書いていて，肝心の全体テストを通しで実行するなどのネタが書かれていない． じゃあ実際に公開してるリポジトリでも見てみるかと思い，patchtag を見ても今度は公開してる人の殆どがテスト書くとかしてなかった．Haskel
単体テストの設計方法について出題・講義 - 千里霧中
少し前になるけれど、先日WACATE SNSというテストコミュニティつながりのテスト設計のワークショップ勉強会で、テスト設計に関する課題を出題・解説をさせていただいた。開催者の方や参加者の方にはお礼申し上げます。 テーマにはリファクタリングのための単体テスト設計を選ばせて頂いた。課題も解答も即興で作ったテキストデータなので、今回は復習も兼ねて補足したものを以下に転載したいと思う。 (諸事情により非表示化しています)
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
Good Enough とは
Good Enough とは １９９５年に、ソフトウェアの世界に新しい品質の概念が持ち込まれました。それが「Good Enough」という概念です。それまでの品質の概念では、バグは一つでも許されませんでした。まさにゴキブリと同じで、１匹でもいたらダメという状況でした。たとえ、それが大した悪さをしなくても、存在そのものが“悪”と認識されるのです。もちろん、今でも、バグが“許されている”わけではありませんが、増える一方の機能に対して、一定の要件の範囲で、あらゆる組み合わせのテストを実施することができなくなったし、そのことに経済的合理性が認められなくなったのです。 汎用コンピュータの時代とちがって、たとえばＰＣのＯＳは精々２万円前後の値段でする。そのようなソフトに対して汎用コンピュータの時と同じようなテストを実施することに合理的な理由を失ってしまったのです。いや、ＰＣのＯＳと言っても、操
Jumble使ってみた - 気付いたとき、気が向いたとき。by ykhr
すげー面白い。 プラグインもあるので、さくっと試せるし。 というわけで、簡単にまとめてみる。 概要 Jumbleとは 作成したテストケースの有効性を検証するツール。 テストケースの点数を0%(悪い)から100%(良い)の値で出力する。 どーやって検証するのか テスト対象クラスを動的に変更しながら既存のテストケースを流して判定する（っぽい）。 テスト対象クラスを変更してもテストケースが失敗しない場合、いけてないテストケースとなる。 クラスの変更箇所 クラスの次のようなポイントを変更する。 条件 二項演算子 インクリメント・デクリメント インライン定数 コンスタントプールの定数（って表現はびみょー？） 戻り値 Switch文 条件と二項演算子以外は、オプションで任意に指定できる。 サンプル まずはテスト対象クラス。 # 拡張子を返却するようなどーでもいいロジック。 # 一部いけてないのはわざと
RSpecを使ったテストコードを読もう
RSpecを使ったテストコードを読もう：Railsコードリーディング～scaffoldのその先へ～（2）（1/4 ページ） 優れたプログラマはコードを書くのと同じくらい、コードを読みこなせなくてはならない。優れたコードを読むことで、自身のスキルも上達するのだ（編集部） 第1回「コードリーディングを始めよう」では、Railsアプリケーションの基本であるCRUDのソースコードを読解しました。最低限の基本の動きということで、ディレクトリ構造の説明すら割愛していたので、今回はディレクトリ構造の解説から行います。その後、今回のメインテーマであるテストコードのコードリーディングに入っていきます。 ここで扱うテストコードというのは、Javaの世界でいうとJUnitを使ったテストコードと同じ粒度、つまり、単体テストに近い粒度のテストケースを動くプログラムで表したものになります。Javaの開発者にとってのJ
デュアルプログラミングとエクソシストゲーム - 檜山正幸のキマイラ飼育記 (はてなBlog)
ここ何年か考えているテーマのひとつが「カジュアルなフォーマルメソッド（語義矛盾は承知）」なんですよ。一連の{テスト(Test), 仕様(Specification), 振る舞い(Behaviour/Behavior)}駆動開発なんて動きは、カジュアルなフォーマルメソッドなんだと僕は捉えているわけですが、もう一歩踏み込んで欲しい感じ、隔靴掻痒の不満もあります。 そこでメイヤーに戻って「契約駆動」とか、あるいは「検証駆動」なんて言葉も使ってみたけど、ナントカ駆動には食傷気味。"Offencive Programming"は、「攻撃的プログラミング」と訳されると真意がまったく伝わらないし、、、 紆余曲折の末、「デュアルプログラミング」って言葉を使うことに（暫定的だけど）決めました。そしてエクソシストゲームは、デュアルプログラミングを説明するために案出した“極端化した比喩”です。 内容： 設計（仕
TDDの勘所とTDD支援超簡易Emacs Lisp - aike’s blog
日本PostgreSQLユーザ会北海道支部 / Ruby札幌 合同セミナーに行ってきました。濃い話がいろいろ聴けましたが、今回一番の目的は角谷さんによるRSpecの実演。 人が目の前でコーディングしているのを見るのは勉強になりますね。注目すべきは結果的に入力されたコード以外の部分にあって、キータイプ速度の緩急や、コピペ操作、バックスペースでの修正等を見ていると、そのとき考えていること（考えるべきこと）が浮かび上がってくるような感じがします。 TDD（テスト駆動開発）については、「実際のところ、どこを厳密にやって、どこで手を抜くべきなのか」についてちょっと指針が見えたように思います。 今回一番厳密に守っていたのは「Think」「Red」「Green」「Refactoring」のモード切り替え。今どこのモードで作業をしているのかを意識して、例えばテストNGが残っている状態(Red)では絶対にリ
いまさらTDDを見直す - Inemuri nezumi diary(2007-07-25)
_ いまさらTDDを見直す いまさら「フェルマーの最終定理 (新潮文庫) 著:Simon Singh 訳:青木 薫」を読んだ*1。この本はすごくいい。 この本が指し示していることのひとつは、皆、汗かいて土木作業してたってことだ。ピタゴラス、ユークリッド、…、オイラー、ガウス、…、ソフィー・ジェルマン、…、志村=谷山…。 綺麗な命題/予想を産み出した彼/彼女らは、手を動かす計算をむちゃくちゃな量やってる。 型理論によれば、型は命題で、実装は証明にそれぞれ対応する。そして、テストは、実装の仕様記述の一部に対応する。具体例を計算することはテストすることだ、と言える。 つまり、XPとかTDDとか誰かが言い始めた2000年前から、数学家はひたすらテストファーストだったってこと。証明/予想を言い終えた後は、テストの結果は焼いて捨てたから残っていない。 反論もありそうなことを敢えて言うが、私自身、テスト
Trace
Debug.Trace を使う nobsun(2007/07/04 10:53:31 JST) Haskellでもprintfデバッグのようなことをしたいことがある．このとき Debug.Trace モジュールにある trace という関数が便利である． trace :: String -> a -> a この関数は値としては第二引数をそのまま返す関数なのだが，その値が評価さ れたときにコンソールに第一引数で与えた文字列を表示するというののである． たとえば， add :: Int -> Int -> Int add x y = trace "'add' called" (x + y) と定義して add 1 (2*3) を評価すると *Main> 1 + add 2 (3*4) 'add' called 15 となる． ジョイントにながれるデータを見る Haskellのプログラミングでは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
Microsoft Developers Deny Report That Windows 2000 Is Bug-Infested - IT Channel - IT Channel News by CRN
ZDNN: Windows 2000に「6万3000の問題」
Haskell のテスト環境 HUnit QuickCheck - Inemuri nezumi diary(2007-07-20)