Python-doctestとunittestの比較[終了]

私はPythonでユニットテストを開始しようとしていますが、誰かがdoctestとunittestの長所と短所を説明できるかどうか疑問に思っていました。

それぞれにどのような条件を使用しますか？

どちらも貴重です。unittestの代わりにdoctestとnoseの両方を使用しています。テストで実際にドキュメントとして役立つ使用例がテストで示されている場合は、doctestを使用します。一般に、これらのテストを包括的にすることはせず、情報提供のみを目的としています。私は効果的にdoctestを逆に使用しています。私のdoctestに基づいてコードをテストするのではなく、コードに基づいてドキュメントが正しいことを確認するためです。

その理由は、包括的なdoctestはドキュメントを乱雑にしすぎるため、使用できないdocstringsまたは不完全なテストのいずれかになるということです。

実際にコードをテストする場合の目標は、例によって何が行われるかを示すのではなく、すべてのケースを徹底的にテストすることです。これは、他のフレームワークでより適切に満たされると思う別の目標です。

私はunittestをほぼ排他的に使用しています。

たまに、doctestで使用できるものをdocstringに入れます。

テストケースの95％はユニットテストです。

どうして？私はdocstringをいくぶん短くして、要点を維持するのが好きです。場合によっては、テストケースがdocstringを明確にするのに役立ちます。ほとんどの場合、アプリケーションのテストケースはdocstringに対して長すぎます。

doctestingのもう1つの利点は、あなたのコードがあなたのドキュメントが言っていることを確実に実行できることです。しばらくすると、ソフトウェアの変更により、ドキュメントとコードが異なる動作をするようになります。:-)

私はバイオインフォマティシャンとして働いており、私が書くコードのほとんどは「1回、1タスク」のスクリプトであり、1回または2回だけ実行され、1つの特定のタスクを実行するコードです。

この状況では、大きなユニットテストを書くのはやり過ぎかもしれませんし、doctestは有用な妥協案です。これらは記述が速く、通常はコードに組み込まれているため、別のファイルを開かなくても、コードの動作を常に監視できます。小さなスクリプトを書くときに便利です。

また、doctestは、プログラミングの専門家ではない研究者にスクリプトを渡す必要がある場合にも役立ちます。一部の人々は、ユニットテストがどのように構成されているかを理解するのが非常に難しいと感じています。一方、doctestは簡単な使用例なので、コピーして貼り付けるだけで使用方法を確認できます。

だから、私の答えを再開すると：doctestは、小さなスクリプトを書く必要がある場合や、それらを渡したり、コンピューター科学者ではない研究者に見せたりする必要がある場合に役立ちます。

単体テストのアイデアを始めたばかりの場合doctestは、使い方がとても簡単なので、まず始めに説明します。また、ある程度のドキュメントも当然提供されます。また、を使用してより包括的なテストを行うにdoctestは、外部ファイルにテストを配置して、ドキュメントが煩雑にならないようにします。

私はお勧めしunittest、あなたが他の場所となっていると一般的に同じ方法で、ライトユニットテストにできるようにしたい使用JUnitのか、似たような、持っていることの背景から来ている場合。

私は独占的にunittestを使用しています。doctestはメインモジュールを乱雑にしすぎていると思います。これはおそらく、完全なテストを書くことに関係しています。

両方を使用することは、有効でかなり単純なオプションです。doctestモジュールが提供DoctTestSuiteとDocFileSuite、それぞれのモジュールまたはファイルからunittestの互換性テストスイートを作成する方法を。

したがって、私は両方を使用し、通常はほとんどまたはまったくセットアップを必要としない関数（引数の単純な型）を使用した単純なテストにdoctestを使用します。実際には、いくつかのdoctestテストが機能を損なうのではなく、機能の文書化に役立つと思います。

しかし、より複雑なケースや、より包括的なテストケースのセットでは、制御と柔軟性を高めるunittestを使用しています。

unittestの代わりにdoctestを使用しません。2つのモジュールは少し重複していますが、同じ機能はありません。

• 私unittestは単体テストフレームワークとして使用しています。つまり、変更がコードの残りの部分に与える影響をすばやく判断するのに役立ちます。

• 私はdoctest、コメント（つまり、docstrings）が現在のバージョンのコードに関連していることを保証するために使用します。

私が得たテスト駆動開発の広く文書化された利点unittest。doctest古くなったコメントがコードのメンテナンスを誤解させるはるかに微妙な危険を解決します。

私はほとんどdoctestを使用しません。コードを自己文書化したいのですが、docstringsはユーザーに文書を提供します。IMOがモジュールに数百行のテストを追加すると、ドキュメント文字列がはるかに読みにくくなります。また、必要に応じて単体テストを変更する方が簡単です。

Doctest時々間違った結果につながることができます。特に出力にエスケープシーケンスが含まれている場合。例えば

def convert():
    """
    >>> convert()
    '\xe0\xa4\x95'
    """
    a = '\xe0\xa4\x95'
    return a
import doctest
doctest.testmod()

与える

**********************************************************************
File "hindi.py", line 3, in __main__.convert
Failed example:
    convert()
Expected:
    'क'
Got:
    '\xe0\xa4\x95'
**********************************************************************
1 items had failures:
   1 of   1 in __main__.convert
***Test Failed*** 1 failures. 

また、出力のタイプもチェックしません。出力文字列を比較するだけです。たとえば、それが整数の場合、整数のように出力するあるタイプの有理数を作成しました。次に、有理数を返す関数があるとします。そのため、doctestは、出力が有理整数か整数かを区別しません。

私は、ディスカバリー・ベースのシステム（「nose」と「py.test」、現在は前者を使用）を好みます。

doctestは、テストがドキュメントとしても優れている場合に適しています。そうでない場合、コードが煩雑になる傾向があります。