我々の産業は、中間結果を生成し、機能要件を (そのつど) 再考すれば、ひどいシステム開発の遅れを回避できるということを学んできました。また我々は、単体テストと機能テストを定期的に実行していれば、バグのよ り少ないシステムを構築できるということも学んできました。しかし、アプリケーションのパフォーマンスを考えたとき、我々はアプリケーションが完成に近づ くまでは、パフォーマンスのテストを滅多に行いません。我々が機能テストで行ってきた、反復、自動化、継続という教えをパフォーマンスについても同様に適用できるでしょうか？
http://www.infoq.com/jp/articles/iterative-continuous
また、パフォーマンスに関する他の記事をご覧になりたい方は、以下URLで表示される一覧よりお選びください。
http://www.infoq.com/jp/performance-scalability
今日我々は、単体テストの完了を伴うビルドは時間ごと、日ごと、もしくは週ごとに行われるべきか、議論を戦わせています。100%のカバレッジと 50%のカバレッジのどちらを目指すべきかについても議論していることでしょう。そのプロセスの詳細についても論戦し、話し合い、熟考していることでしょ う。しかし、単体テストを伴う自動ビルドを実行する事はベストプラクティスである、と言う点についてはほとんど全ての人が賛同します。しかしパフォーマン スのテストに関しては、限られた議論しかされていないか、全く行われていません。
続きをご覧になりたい方は、以下URLよりご覧ください。
http://www.infoq.com/jp/articles/iterative-continuous
また、パフォーマンスに関する他の記事をご覧になりたい方は、以下URLで表示される一覧よりお選びください。
http://www.infoq.com/jp/performance-scalability