Unit testing isn't enough. You need static typing too.
When I was working on my research for my Masters degree I promised myself that I would publish my paper online under a free license, as soon as I had graduated. Unfortunately there seems to be an unwritten rule of Graduate School research. You spend so much time focusing on a single topic of study that by the time you graduate you are sick of it. So more than year later I'm finally putting my pape
ユニットテストの保守性を作りこむ, xpjugkansai2011
シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン（規律）の存在」や「General Electric（GE）やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/
わんくま同盟
メニュー わんくま同盟 勉強会情報 メンバリスト 掲示板 ブログ リンク わんくま同盟 C#, VB.NET 掲示板 ライセンスオンライン コメント リンクはご自由にどぞ。 上のバナーでどぞ。 バナーは直リンクでどぞ。 09/10 大阪勉強会 #79 上記イベント 申し込み受付中 わんくま同盟 名古屋勉強会 #20 ＆ 第39回 名古屋アジャイル勉強会 ＆ TEF東海 勉強会 後援:/GITCA 今回の勉強会情報 2012年最初のわんくま勉強会は、名古屋アジャイル勉強会及びTEF東海と３つのコミュニティが合同でお贈りする、テスト＆TDDワークショップ！ ※ワークショップ・・・参加者の方が実際に手を動かして学習を行うスタイルの勉強会の事。 ソフトウェア開発におけるテストってなんなのか、テストを行う事で品質は上がるのか、また開発手法の1つであるTDD(テスト駆動開発)ってどうやるのか、参加者の
自動テストのレベル分け
最近は、「xUnit で UnitTest を書いてカバレッジとってます」なんて、どいつもこいつも謳ってるけど、お前らマジかと。それで出来てるつもりなのかと…? というわけで、秋の朝がさわやかなので、自動テストの出来てる度合いの段階区分を考えてみたい。 Level 3: 出来てる：常時テスト成功、高カバレッジ ちゃんとできてるプロジェクトの出来る子ちゃん達からしたら、取り立てて言及することもない当たり前の状態だと思う。 "Clean Check-In" が普通に守られているから、当然、テストも常時全件成功する。まあ基本中の基本。 で、TDD/TestFirst で開発してるから、開発の最初期から高カバレッジ（計測対象範囲内でのカバレッジ基準充足）で始まり、進捗に伴いソースコード量が増えていく中でも、高カバレッジを維持したまま推移する。 Level 2:怪しい：ほぼ常時テスト成功、低カバレッ
なぜUnitTestは理解されない？
TwitterでこんなTweetが流れた… エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに？ 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...） テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...） UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの ＝ テストコード テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使
テストコードのリファクタリング - 千里霧中
ユニットテストの再利用や継続的利用を行おうとすると、テストコードにも保守性等に優れた良い設計が求められるようになります。そこで出番が増えてくるのがテストコードのリファクタリングです。 ただ現状、テストコードのリファクタリングはいくつか課題を抱えています。今回はその課題の１つである「リファクタリング前後でテストコードの振る舞いが変わっていないかチェックするテスト」（以下リファクタリングの回帰テスト）の実現方法についてまとめます。 テストの回帰テスト まずリファクタリングの回帰テストを真っ当に考えていきます。テストコードをテスト対象としてみると、一般的に以下の特徴が見えてきます。 SetupメソッドやMockオブジェクト等を通して、テスティングフレームワークから間接入力を受けます。 Assertionメソッド等を通して、テスティングフレームワークに対して間接出力を行っています。またMockオブ
テスト駆動開発チートシート - やさしいデスマーチ
TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
今すぐフォローしておきたいAndroid テストクラスタ
Amazon.co.jp: Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck)): Steve Freeman, Nat Pryce: 本