【问题标题】:Setting output file for tests with SetUp method使用 SetUp 方法为测试设置输出文件
【发布时间】:2018-10-12 08:32:11
【问题描述】:

您好,我有一个充满testcase-s 的class。我想根据他的标识符或名称预设每个testcase 输出文件。

class SetTests {
        [SetUp]
        public async Task WriteHeader() {
            TestContext.WriteLine("${something belonging to current test}");
        }

        [TestCase]
        public void WriteContent() {
            TestContext.WriteLine("Myfirst test");
        }
        [TestCase]
        public void WriteAnotherContent() {
            TestContext.WriteLine("mysecond test");
        }
    }

我希望在每个 testcase 之前调用我的 WriteHeader 方法将当前测试 Output 文件名设置为可以识别当前测试的名称(Methodinfo.Name 或任何其他独特属性),并编写这也是文件中的标题。

在我上面的示例中,我希望在运行测试后:

WriteContent.txt

//----ID/name/ of test whatever-----
Myfirst test

WriteAnotherContent.txt

//------ID/name/ of test whatever------
  my second test

P.S我说whatever是因为我不知道metadata可以在SetUp方法中获得什么关于即将运行的测试的信息。

【问题讨论】:

    标签: unit-testing .net-core nunit


    【解决方案1】:

    根本无法使TestContext.WriteLine 的输出转到any 文件,因为它被定义为写入由NUnit 创建的XML 输出报告。 Console.WriteLine 也是如此,它会被 NUnit 拦截并包含在 XML 输出中。

    为了让您的测试写入其他地方,即写入一个特殊文件,您必须自己打开该文件并写入它。所以问题是双重的......

    1. 如何确定在 SetUp 中写入哪个文件。

    2. 如何确保每个测试都获得该信息并写入正确的文件。

    两者都很容易如果没有并行运行的测试,否则就更难了。

    非平行方法

    TestContext.CurrentContext.Test.Name 为您提供当前测试的名称。它在 SetUp、TearDown 和测试本身中可用。当测试按顺序运行时, SetUp、Test 和 TearDown 一个接一个地运行,中间没有任何内容。您可以在SetUp的成员字段中设置信息,并在测试和拆解中使用。

    示例:在 SetUp 中,构造文件名,创建它并将 TextWriter 保存在字段中以供测试使用。在测试中,写信给那个作者。在 TearDown 中,将其关闭。

    另一个示例:在 SetUp 中,创建一个字符串编写器(或只是一个 StringBuilder)来保存输出。在测试中,写入作者(或附加到构建器)。在 TearDown 中,找出要使用的文件的名称并将所有内容写出来。

    注意:如果测试并行运行,这将不起作用。 保存在实例中的任何信息都可能随时被同一类中的另一个测试覆盖。要使用这种方法,您应该将整个夹具(或每个测试)标记为[NonParallelizable]

    并行方法

    如果测试要并行运行,则不能更改夹具实例中的任何信息。每个写语句都必须找出要写入的文件并附加到它。做到这一点的最好方法是通过写作的方法。它应该使用一个锁来确保它不会被两个线程同时进入。伪代码...

    Lock based on the fixture instance or an object created in the constructor.
        Use test name to get file name
        Open the file for appending
        Write to the file
        Close the file
    

    如果您不使用并行执行,那么使用更简单的非并行方法没有任何问题。但如果你这样做,请务必将测试标记为不可并行化。否则,您可能会冒着稍后有人(甚至是您自己健忘的自己)出现的风险,并在更高级别添加一个属性,使测试默认并行运行。

    【讨论】:

      猜你喜欢
      • 2011-05-29
      • 1970-01-01
      • 2012-12-17
      • 1970-01-01
      • 1970-01-01
      • 2017-01-16
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多