タグ

testingに関するsawatのブックマーク (5)

  • Android Bindingを改めて使ってみた(1) - タイトルは未定

    田さんのエントリ「android-binding使ってみた « Code Archives」でトラックバックをもらったこともあって改めてAndroid Bindingについて考えてみました。ベースは半年前のエントリです。Android Bindingを使ってみた(1) - タイトルは未定Android Bindingを使ってみた(2) - タイトルは未定Android Bindingを使ってみた(3) - タイトルは未定このエントリでの最終的なコミットはこちらhttps://github.com/nakaji/AndroidBindingSample/commit/1640c95546fff70218eeac050a8b7c4bb4f85ff1 当初の目的と前回までの課題自分でもすっかり忘れてたので復習。目的ユニットテストを行いやすくしたい 画面(View)とロジック(ViewModel

  • Martin Fowler's Bliki in Japanese - テストの癌

    http://martinfowler.com/bliki/TestCancer.html 2007/12/6 の執筆に専念するようになってから、ソフトウェア開発の現場と疎遠になるのがよく心配になる。 これまでに現場を離れた有名人を何人も目にしているが、私は彼らと同じような運命をたどりたくはない。 私にはThoughtWorksという最高の情報源があるので、まだ地に足をつけていられるのだ。 ThoughtWorksはまた、現場からのアイデアの源でもある。 同僚が発見し開発したものについて書くことは楽しい。 当に役に立つものなので、読者のみなさんには是非とも使ってもらいたい。 さて、日の話題は、あまり気持ちのいいものではない。 答えの出ていない問題についてである。 話はこうだ。 我々はプロジェクトを成し遂げ、ピッカピカのソフトウェアをクライアントに納品した。 納品時には自動テスト一式も

  • for 文を setTimeout に変換する - IT戦記

    for 文で 100 項目とか 1000 項目とかあるテストケースを処理するとブラウザが固まる。 こんなダイアログが表示されます。 ということで for 文を setTimeout や setInterval に変換する事で定期的にブラウザに処理を戻すことができる。 // ここでは console.log のところでログを取ってますが // 通常は処理が入ります。 for (var i = 0; i < 3; i ++) { console.log('a' + i); } /* * 結果 * a0 * a1 * a2 */ これをまず while 文に変換 var i = 0; while (true) { if (!(i < 3)) break; console.log('a' + i); i ++; } /* * 結果 * a0 * a1 * a2 */ で、 setTimeout に

    for 文を setTimeout に変換する - IT戦記
    sawat
    sawat 2007/11/08
    後はこの変換を自動化すれば完璧だね!
  • JavaでRubyのfixtureみたいなことをしよう - Fixtureを作りました - 矢野勉のはてな日記

    Java Ruby on Railsのfixtureという機能は有名なので皆さんご存じかと思います。JavaでいうJUnitのTestCaseクラスに、 fixture :test と書くだけでtestというテーブルにtest.ymlという名前で用意されたテストデータが投入されるという機能です。 同じような機能はJavaでもかなり以前からDbUnitとして提供されてきましたが、使い勝手という点で圧倒的にfixtureが勝っている。というのは、DbUnitは汎用的なライブラリなので使うためにはDBへの接続定義をコードで書いたり、ロードするxmlファイルを探したり、といろんな手間があったのです。 DbUnitはデータベーステストのデファクト・スタンダードなのでJavaプログラマなら一度くらいは使ったことがあるかと思います。私も仕事柄いろんなところのアプリケーション開発環境を構築するのを手伝いま

  • バグを見つけるためのテストをしよう

    「一生懸命テストしたのに、どうしてもバグがなくならない。」これは、すべてのソフトウェア開発者に共通する悩みであろう。 バグのあるソフトウェアでも、リリース前には、膨大なテスト項目をクリアしてきたはずだ。だが、そのほとんどは、仕様書や設計書から書き写しただけの、機能が正しく動くことを確認するものばかりになってはいないか。 テストしても見逃されるバグは、ソフトウェアを使い込んだり、ちょっと変わった操作をしたり、ある特殊な状況でのみ発生するものが多い。このようなバグは、意図的にバグを見つけようとしない限り、見つからないものである。 ソフトウェアテストも、創造性を問われる仕事である。ソフトウェアテストに関する広汎な知識と、豊かな想像力で、バグを見つけられるようなテストを創り出していかなくてはならない。それができなければ、ソフトウェアの品質も向上しない。 確認のためのテストと、バグを見つけるためのテ

  • 1