...データベースは doctest 間で更新されないため、doctest で特定の状態が必要な場合は、データベースをフラッシュするか、フィクスチャをロードすることを検討する必要があります。
率直に言って、現在、私のテストの 90% は doctests で行われています。私の同僚は、それは奇妙だと思っていました。正直なところ、私はほとんどテストを行っていないので、その分野の達人であるふりをするつもりはありません。
テスト方法を決定するときに使用する経験則を持っている人はいますか?
私の同僚は、単体テストを介して doctest およびビューとしてモデルの機能と制約をテストすることを提案しました。経験則として、それはどのように聞こえますか？
プロジェクトが成長するにつれて、コードのテストには単体テストの方がはるかに優れていることがわかります。
Django プロジェクト自体は、すべての doctests を unittests に変換中です (1.3 リリースまでに完了する予定です)。これを行っている理由は、この変換の前は、テスト スイートでの実行順序によって、再現が困難なエラーが発生することがあったためです。一部のコードが、以前に実行した doctest コードに誤って依存する場合があります。さらに、単体テストに切り替えると、データベースをクリアする方法とタイミングをより慎重に判断できるため、全体的なテスト時間が短縮されます。
単体テストのもう 1 つの利点は、保守が非常に簡単なことです。テスト ケース全体が自己完結型であるため、別のテスト ケースを作成するか、対象を絞った小規模なテスト関数を適切に変更します。
Doctests は進化によって機能する傾向があります - ウィジェットのインスタンスを取得し、緑の毛皮を追加し、毛皮が緑であることを確認し、4 本の足を追加し、4 本の足と緑の毛皮があることを確認し、親指を追加し、親指があることを確認します。 、4 本の足、緑の毛皮など...つまり、緑の毛皮ステージの直後にテストを追加する場合は、後続の他のすべてのテスト ケースの期待される結果を変更する必要があります。
この書き直しはすべてやりたくないので、最後に新しいテストを追加します。次に、別の機能を追加すると、しばらくすると、テストが絶望的にごちゃ混ぜになり、特定の機能がテストされているかどうかさえわからなくなります。単体テストでは、各テストが特定の具体的で限定されたアイデアを具現化するため、テストを論理的に並べ替えたり、以前のすべてのテストに依存しない新しいテストを追加したりすることがはるかに簡単になります。さらに、add_green_fur()動作方法を変更すると、何十ものテスト ケースの結果を変更する必要がなくなります。
もう 1 つの利点は、(適切に記述された場合) 単体テストが、コードが失敗した場所を正確に教えてくれることです。Failed: MyWidget.tests.test_green_fur()実際の障害点から数十から数百行離れていることが多い「384行目でウィジェットテストが失敗しました」よりもデバッグがはるかに簡単です。
一般に、ユニットテストはテストするためのより良い方法です。
編集：
あなたの同僚の考えに応えて、私は彼が多くのドキュメントテストを伴う大規模なプロジェクトに取り組んでいないことを丁重に提案します。モデル内の Doctest は、ビュー内と同じくらい悪いものです。それらはまったく同じ問題を抱えています (どちらかといえば、doctestflushは非常に高価であり、完全な doctest には絶対に必要であるため、モデルではより悪いです)。テストの実行にかかる時間のコストを過小評価しないでください。
また、非常に正当な理由がない限り、テストの種類を混在させないでください。そうした場合、テストを二重に行ったり、たまたま見ていないテスト スイートで関数がテストされていると仮定したりすることにすぐに気付くでしょう。
Doctest は、コードがどのように動作するかについての「ドキュメントを提供する」ものとして宣伝されることがよくあります。それはいいことですが、読みやすいインライン コメントを付けて読みやすいコードを書く代わりにはなりません。さらにドキュメントが必要な場合は、個別に記述してください。
優れたドキュメントとしても機能する優れたテストを作成することはできません。
Doctests は、ドキュメントが最新であることを確認するのに最適ですが、コードのテストには実際には使用しません。コードに変更を加えると、ドキュメントが古くなってしまうのは非常に簡単です。
つまり、単体テストを使用してコードをテストし、doctests を使用してドキュメントをテストします。