0

注:私は C# コードで依存性注入を使用することに慣れていますが、私が理解していることから、Ruby や Python などの動的言語は LEGO ではなく play-doh のようなものであるため、IoC コンテナーを使用する必要はありません。 IoC パターンがまだ有用かどうかについて議論します。.patch以下のコードでは、コードのモック/スタブに必要な継ぎ目を提供するfudge の機能を使用しました。ただし、コードのコンポーネントは結合されています。私はこれが好きかどうかわかりません。This SO answerは、動的言語での結合が静的言語よりも緩いことも説明していますが、その質問では、IoC 用のツールは不要であるがパターンは不要であるという別の回答を参照しています。したがって、副次的な質問は、「これに DI を使用する必要があったか?」ということです。

次の python フレームワークを使用しています。

結果の製品コードは次のとおりです。

def to_fasta(seq_records, file_name):
    file_object = open(file_name, "w")
    Bio.SeqIO.write(seq_records, file_object, "fasta")
    file_object.close()

今、私はこのコードをTDDしましたが、次のテストでそれを行いました(完全ではありませんでした):

@istest
@fudge.patch('__builtin__.open', 'Bio.SeqIO.write')
def to_fasta_writes_file(fake_open, fake_SeqIO):
    fake_open.is_a_stub()
    fake_SeqIO.expects_call()

    seq_records = build_expected_output_sequneces()
    file_path = "doesn't matter"

    to_fasta(seq_records, file_path)

4 フェーズ テストパターンに従っていることを確認するために、更新されたテストと明示的なコメントを次に示します。

@istest
@fudge.patch('__builtin__.open', 'Bio.SeqIO')
def to_fasta_writes_file(fake_open, fake_SeqIO):    
    # Setup
    seq_records = build_expected_output_sequneces()
    file_path = "doesn't matter"
    file_type = 'fasta'

    file_object = fudge.Fake('file').expects('close')

    (fake_open
        .expects_call()
        .with_args(file_path, 'w')
        .returns(file_object))

    (fake_SeqIO
         .is_callable()
         .expects("write")
         .with_args(seq_records, file_object, file_type))

    # Exercise
    to_fasta(seq_records, file_path)    

    # Verify (not needed due to '.patch')
    # Teardown

2 番目の例はより徹底していますが、このテストはやり過ぎですか? TDD Python コードのより良い方法はありますか? 基本的に、私はこの操作の TDD をどのように行ったかについてのフィードバックを探しています。また、テスト コードまたは製品コードのいずれかを記述する別の方法を歓迎します。

4

1 に答える 1

1

この関数が何をするのかを考え、実際に何を担当しているのかを考えてください。私には次のように見えます: いくつかのデータとファイル名を指定すると、特定の形式 (fasta) でレコードをファイルに書き込みます。実際には、Python ファイル I/O の動作や Bio.SeqIO の動作については責任を負いません。

2 番目のバージョンでは、次のことがテストされます。

  1. ファイルは書き込み用に開かれます。
  2. その Bio.SeqIO.write は、予想されるパラメーターで呼び出されます。
  3. ファイルは閉じられています。

それはかなり良さそうです。これのほとんどは単純で、やり過ぎだと言う人もいるかもしれませんが、TDD のアプローチは、ファイルを閉じるなどのことを行うように促すのに役立ちます (当然のことですが、私たちは常にそのようなことを忘れています)。これらのテストは、Bio.SeqIO.write が将来、異なるパラメーターを期待するように変更されることも防ぎます。ライブラリのバージョンをアップグレードしてプログラムが壊れる理由を考えるか、ライブラリのバージョンをアップグレードしてテストを実行し、その理由と場所を知ることができます。

当然、ファイルを開けない場合や、Bio.SeqIO.write がスローする可能性のある例外の場合に備えて、他のテストを作成する必要があります。

于 2013-07-13T17:22:14.643 に答える