読者です 読者をやめる 読者になる 読者になる

ユニットテスト

Software Development Poll: Programming, Testing, Open Source, UML, Agile, Tools, Web

[日本語訳]
ユニットテストはまだ広く非公式です。

この投票はどのように組織がユニットテストを行っているか調査したものだ。
これは、プログラム開発の後、時間があれば結合される前にすでに実施されているのでしょうか、もしくはプログラム開発の努力の鍵となる要素でしょうか?

質問: あなたの環境ではどのようにユニットテストをしていますか?



ユニットテストをしていない                     17% (2008) 13%(2006)
非公式でユニットテストをしている                 40%(2008)  46%(2006)
ユニットテストケースがドキュメント化されている         9%(2008)   11%(2006)
ユニットテストケースと実行結果がドキュメント化されている  14%(2008)  16%(2006)
テスト開発駆動を実施している                   20%(2008)  14%(2006)



参加者: 384人 (2006年は460人)
完了日: 2008年10月 (2006年2月)


以前の調査に比べてたくさんのTDD習熟者が育っている事実にもかかわらず、あなたはユニットテストがまだ非公式のマナーとして広がっていることに気付くでしょう、それは開発者にとって簡単に無視できないことです。
多くの人々がアジャイルアプローチの一般的な採用を発表した時これは奇妙に思えましたが、しかし私たちの調査の結果は同じトピックにおける他の多くの投票と同様です。
2つの調査を比べてみると、すでに正式にユニットテストを行っていた人々がTDDアプローチに切り替えたように思えます。
ユニットテストをしない人々が異なった理由を持っています。 ある人は、彼らが自分達の開発プロセスに価値を高めないと単に考えるでしょう。(開発プロセスを信じるのは時々難しいです)。 その他の人は、時間が無い、もっと簡単に理解できる。
たくさんの人がユニットテストは書きにくいと不平を言いますが、しかし良いユニットを作成することは、あなたのコードが何をするべきであるかを理解しているという証拠です。 私は同意します。しかしながら、要件が絶えず変化するのであれば大きいライブラリのユニットテストのスクリプトを維持するのは難しいかもしれません。 例えば、ユニットテストを実行しない「良い」理由は、WEBアプリケーションのクライアント側がこのいくつかのテストに適用できないといったことが考えられます。 また、テストチームを別に持っているいくつかの組織があります。
彼らの開発者は、彼らのアプリケーションを検査するためにQAに完全に頼るでしょう。 また、あなたはソフトウェアに非常に限られた余命しかないとき、ユニットテストをする価値がないと考えるでしょう。