私が参加しているプロジェクトの仲間の開発者は、doctest は単体テストと同じくらい優れており、コードの一部がdoctest されている場合、単体テストを行う必要はないと考えています。私はこれが事実であるとは思わない。doctests が単体テストの必要性を置き換えるという議論に賛成または反対する、堅実で理想的に引用された例を誰かが提供できますか?
ありがとう - ダニエル
編集: doctesting が単体テストに取って代わるべきではないことを示す参照を誰でも提供できますか?
私が参加しているプロジェクトの仲間の開発者は、doctest は単体テストと同じくらい優れており、コードの一部がdoctest されている場合、単体テストを行う必要はないと考えています。私はこれが事実であるとは思わない。doctests が単体テストの必要性を置き換えるという議論に賛成または反対する、堅実で理想的に引用された例を誰かが提供できますか?
ありがとう - ダニエル
編集: doctesting が単体テストに取って代わるべきではないことを示す参照を誰でも提供できますか?
何年も前にgmpyプロジェクトを開始したときに、doctest
の代わりに (ab) を使用しました。そのソースを参照して、すべての機能が doctests で徹底的にテストされていることを確認できます (機能は C コードの Python 拡張によって提供され、前回カバレッジ測定のために計測したときは、95% 以上のカバレッジでした)。なぜ私はそれをしたのですか?新品同様でしたので、どこまで押し込めるか興味がありました。unittest
doctest
gmpy
回答: 確かに非常に遠いですが、それだけの価値はありません (目新しさは薄れますが、すべてのテストを書き直したくはないため、gmpy のテストは依然としてすべて doctest のままです)。doctest は、メッセージのほんのわずかなタイプミスの修正でさえもテストに失敗するという非常に脆弱であり、このように悪用されている場合は非常に厄介です。これは、出力を「ゴールデン」(既知の良好な) 期待される出力と比較することに基づく、従来の統合テストのようなものです。最初は簡単に記述できますが、不当なテストの破損を数年間修正した後、余暇に悔い改めるでしょう;- )。
のスタイルが面倒だと思う場合は、 py.testやノーズなど、単体テストで使用することを意図した他unittest
の優れた代替手段があります。もちろん、ドキュメント目的で作成した doctest をテスト バッテリーに追加する価値はありますが、単体テストをそれに置き換えるというテスト メンテナンスの頭痛の種になる価値はありません。doctest
doc テストに賛成も反対も、本当に議論の余地はありません。それらは単なるテストです。実際、python 2.4 では、doctest から単体テスト スイートを作成する方法があります: http://docs.python.org/library/doctest.html#unittest-api
ある意味では、少なくとも機能的な観点からは、doc-tests を単体テストのサブセットと考えることができます。
ただし、python docs では、次のような場合に doctests を使用することをお勧めします。
彼らの主張は、ドキュメント内にテストを書くと、より良いドキュメントとテストの両方を書かざるを得なくなるというものです。単体テストを個別に作成する場合とは対照的に、十分なドキュメントを追加することはめったになく、停滞して古くなる傾向があります。
参照: http://docs.python.org/library/doctest.html#soapbox
統合テストなどのために doctest を書くのはもっと難しいと思います。ただし、python と Django でわかるように、それらは doctest を多用しているため、より理解しやすいドキュメントとチュートリアルが得られます。
それはすべてあなたのプロジェクトに依存します。テストする「正しい」方法はありません。
また、Code Complete 2本を読むことをお勧めします。単体テストは、ソフトウェアに障害がないことを確認する最善の方法ではないことに気付くかもしれません。
Python 標準ライブラリには、doctests だけでは必ずしも十分ではないことを確信させる具体的な例、つまりdecimal
モジュールがあります。60000 を超える個々のテストケースがあります (Lib/test/decimaltestdata にあります)。これらすべてが doctest として書き直された場合、decimal モジュールは非常に扱いにくくなります。テストの数を減らしても十分なカバレッジが得られる可能性はありますが、数値アルゴリズムの多くは非常に複雑であるため、分岐のすべての可能な組み合わせをカバーするには、膨大な数の個別のテストが必要になります。
doctests はいくつかの用途に最適です
単体テストは、さまざまなケースで優れています。
言い換えれば、少なくとも私自身の使用では、自分が何をしているのか (ドキュメントだけでなく設計フェーズも) を説明することに集中する場合には doctest は優れていますが、テストをリファクタリングやコードのシートベルトとして使用する場合は負担が大きくなります。カバレッジ。
doctests を使用して、完全な単体テスト スイートを実装することができます。ただし、doctests は少し制限されているため、通常は単純なドキュメントの例のために予約し、より堅牢な単体テスト フレームワーク (例: unittest
) を実際の詳細な単体テストに使用することをお勧めします。
のもう 1 つの利点unittest
は、テスト フレームワークが、JUnit や NUnit などを使用する別の開発環境から来た人にとって馴染みのあるものになることです。モジュールはdoctest
少し異なります。