メンテナンス可能な自動受け入れテスト
原文(投稿日：2009/12/07)へのリンク 自動テストはすぐに辻褄が合わなくなってしまい、メンテナンスするのが大変だ。従って企業もテストを自動化したがらない、とDale Emery氏は言う。氏は、最近公開したペーパーにテスト自動化に関わる共通の問題を回避するための実践的な方法を記している。これは、典型的な自動化コードから始めて、より強力でメンテナンスしやすいコードに育てていく方法だ。 氏のペーパーの根底にある発想は、テスト自動化はソフトウエア開発だ、ということだ。この発想はシンプルでとても現実化しやすい。Dale Emery氏はこの発想をElisabeth Hendrickson氏から教え込まれた。 ほとんどのソフトウエアにとってメンテナンスは、初期開発以上にコストがかかるものだ。しかも、そのコストはコードの生存期間全般にわたる。テスト自動化の分野では、レコード/プレイバックスクリプト
テスト駆動開発とレガシーコードのトラブル
原文(投稿日：2009/11/19)へのリンク Alan Beljeu 氏は古い (レガシー) C++ コードベースで TDD を行っていて，トラブルに見舞われた。その理由はこうだ。 機能を完全に実装できていないクラスが最後に残ります。いつか必要になるかも知れない，というやつです。他のクラスからそれを利用しようとして，実装を完成させる時がきた，まさにその時になって当初の設計不足が明らかになるのです。設計は新たにやり直し，外部仕様(とそのテスト)も修正が必要。そのクラスを使っていた既存コードも変更しなければなりません。 そして彼は，"事前の大規模設計 (Big Design Up Front)" がこの問題の解決策ではないか，と考えるのだが，アジャイルコーチである George Dinwiddie 氏は，Alan のこの例が訴えているものを指摘する。すなわち，きれいなコード (clean c
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
