スフィンクスの拡張子でdoctestの出力を自動的に生成する

Question

doctestのためにsphinxの拡張について何か不足していると思う。

マニュアルの典型的な例は次のとおりです。自動的：スフィンクスは（1をここに）出力を生成させるための方法は

.. doctest:: 

    >>> print 1 
    1 

ありませんか？私の知る限り理解されるように

、それを実行することが可能である：

$ make doctest 

コードスニペットをテストし、期待される出力と実際の出力を比較する効果を有します。たとえば、あなたが

.. doctest:: 

    >>> print 1 
    3 

のdoctestを持っている場合、それは3を期待している間、それは1を得たことを警告します。

代わりに、実際の出力をdocstringまたは.rstファイルに挿入することをおすすめします。我々のようなものがある場合たとえば、私はそれが可能だと確信している、と希望

.. doctest:: 

    >>> print 1 
    1 
    >>> print [2*x for x in range(3)] 
    [0,2,4] 

：

.. doctest:: 

    >>> print 1 
    >>> print [2*x for x in range(3)] 

を私たちはオプションでmake doctestを実行すると、それがドキュメンテーション文字列を変更することを希望します非常に便利です！

Answer 1

私は強く（しかし親切に）へのアドバイスをお願いします。

何を求めていることはdoctest moduleの「テスト部」に反している：Pythonの対話セッションのように見え、その後、ことを確認するために、これらのセッションを実行したテキストの断片のための

doctestのモジュールを検索し、それら示されているとおりに正確に動作します。

これらのテストは、あなたが入力と期待される出力を書き込むと期待される出力は、実際の出力と一致した場合、Pythonのチェックをしましょう場合の理由がなければなりません。

予想される出力を生成させるようにすると、よく、は（ユーザー/作成者）になることはなくなるため、doctestは決して失敗しないため、これらのテストは役に立たなくなります。

注：関数内にロジック（if/else、while-loops、appendsなど）がない場合、それらをテストする必要はありません。テストではテストロジックを再現してはいけません。さもなければ、彼らはもはやその機能をテストしていません。

テスト駆動開発については、this videoが非常に興味深いと思いますが、この議論についてもっと知りたい場合は、おそらく興味深いかもしれません。ここで

Answer 2

はあなたが私はあなたが探しているかもしれない疑いがあるものを達成できる方法についての提案です：

ダグ・ヘルマンはWriting Technical Documentation with Sphinx, Paver, and Cogと呼ばれる興味深い記事を書いています。 a sectionは、Cogツールを使用して自動的にコード例を実行し、出力をスフィンクスの組み込み文書に含める方法を説明しています。

---

は、特別な runblockディレクティブでコードを実行し、ドキュメントへの出力を添付することができcontributed Sphinx extension called autorunがあります。