0

注意：我习惯于在 C# 代码中使用依赖注入，但据我了解，像 Ruby 和 Python 这样的动态语言就像play-doh 而不是 LEGO，因此不需要遵循使用 IoC 容器，尽管有一些关于 IoC 模式是否仍然有用的争论。在下面的代码中，我使用了 fudge 的.patch功能，它提供了模拟/存根代码所需的接缝。然而，代码的组件因此是耦合的。我不确定我喜欢这个。这个 SO 答案还解释了动态语言中的耦合比静态语言更松散，但确实引用了该问题中的另一个答案，即不需要 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)

这是更新的测试以及明确的注释，以确保我遵循四阶段测试模式：

@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

虽然第二个例子更彻底，但这个测试是否矫枉过正？TDD python代码有更好的方法吗？基本上，我正在寻找有关我如何使用 TDD 执行此操作的反馈，并且欢迎任何替代方法来编写测试代码或生产代码。

4

1 回答 1

1

想想这个函数做了什么，想想你实际负责什么。它看起来像：给定一些数据和文件名，以特定格式（fasta）将记录写入文件。您实际上并不负责 Python 文件 I/O 的工作，或者 Bio.SeqIO 的工作方式。

您的第二个版本测试：

  1. 打开文件进行写入。
  2. 使用预期参数调用 Bio.SeqIO.write。
  3. 文件已关闭。

这看起来很不错。大部分都很简单，有些人可能会称其为矫枉过正，但 TDD 方法可以帮助提醒您执行诸如关闭文件之类的操作（很明显，但我们总是忘记这样的事情）。这些测试还可以防止将来更改 Bio.SeqIO.write 以期望不同的参数。您可以升级您的库版本并想知道为什么您的程序会中断，或者升级您的库版本，运行您的测试，并知道它为什么以及在哪里中断。

当然，您应该为无法打开文件的情况编写其他测试，或者 Bio.SeqIO.write 可能抛出的任何异常。

于 2013-07-13T17:22:14.643 回答