c# - 单元测试 : Self-contained tests vs code duplication (DRY)

Question

我正在迈出单元测试的第一步，但不确定在单元测试中似乎自相矛盾的两种范式，它们是:

• 每个单元测试都应该是独立的，不依赖于其他单元测试。
• 不要重复自己。

更具体地说，我有一个要测试的导入器。导入器具有“导入”功能，获取原始数据(例如，从 CSV 中提取)并返回某种对象，该对象也将通过 ORM(在本例中为 LinqToSQL)存储到数据库中。

现在我想测试几件事，例如返回的对象不为 null，它的必填字段不为 null 或为空，并且它的属性得到了正确的值。我为此写了 3 个单元测试。每个测试都应该导入并获得工作，还是属于一般设置逻辑？另一方面， believing this blog post ，就我的理解而言，后者将是一个坏主意。另外，这不会违反自包含吗？

我的类(class)是这样的:

[TestFixture]
public class ImportJob
{
    private TransactionScope scope;
    private CsvImporter csvImporter;

    private readonly string[] row = { "" };

    public ImportJob()
    {
        CsvReader reader = new CsvReader(new StreamReader(
                    @"C:\SomePath\unit_test.csv", Encoding.Default),
                    false, ';');
        reader.MissingFieldAction = MissingFieldAction.ReplaceByEmpty;

        int fieldCount = reader.FieldCount;
        row = new string[fieldCount];

        reader.ReadNextRecord();
        reader.CopyCurrentRecordTo(row);
    }

    [SetUp]
    public void SetUp()
    {
        scope = new TransactionScope();
        csvImporter = new CsvImporter();
    }

    [TearDown]
    public void TearDown()
    {
        scope.Dispose();
    }

    [Test]
    public void ImportJob_IsNotNull()
    {
        Job j = csvImporter.ImportJob(row);

        Assert.IsNotNull(j);
    }

    [Test]
    public void ImportJob_MandatoryFields_AreNotNull()
    {
        Job j = csvImporter.ImportJob(row);

        Assert.IsNotNull(j.Customer);
        Assert.IsNotNull(j.DateCreated);
        Assert.IsNotNull(j.OrderNo);
    }

    [Test]
    public void ImportJob_MandatoryFields_AreValid()
    {
        Job j = csvImporter.ImportJob(row);
        Customer c = csvImporter.GetCustomer("01-01234567");

        Assert.AreEqual(j.Customer, c);
        Assert.That(j.DateCreated.Date == DateTime.Now.Date);
        Assert.That(j.OrderNo == row[(int)Csv.RechNmrPruef]);

    }

    // etc. ...
}

可以看出，我正在执行行 Job j = csvImporter.ImportJob(row);
在每个单元测试中，因为它们应该是独立的。但这确实违反了 DRY 原则，并且可能有一天会导致性能问题。

在这种情况下，最佳做法是什么？

Answer 1

您的测试类与普通类没有什么不同，应该这样对待:所有良好实践(DRY、代码重用等)也应该适用于此。