为什么以及如何在遗留应用程序代码中实施初始单元测试

Question

我正在将单元测试集成到现有的遗留应用程序中。在《使用遗留应用程序》一书中以及我读过的许多其他书中，都写到，在开始重构现有代码或集成新功能、纠正错误等过程之前，您始终应该编写单元测试

......在我阅读的示例中，重构方法的签名永远不会或很少中断，并且旧的单元测试在经过大量更改后仍然有效。原因是作者代码并不像我每天使用我认为的“遗留代码”时查看的代码那么遗留。

实际上，当您拥有遗留应用程序时，代码非常糟糕，以至于您必须破坏方法的签名。如果您尝试使用原始方法编写单元测试，那么在仅仅 5 分钟的更改之后，您将破坏整个签名，并且第一个测试将被发送到垃圾箱。

举个例子，看看下面的代码：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace MyCompany.Accouting
{
    public class DataCreator
    {
        public static System.Data.DataSet CreateInvoice(
            System.Data.DataSet customer, 
            System.Data.DataSet order, 
            string mails, 
            ref bool isValid)
        {
            System.Data.DataSet invoice = new System.Data.DataSet();

            int taxGroupId =
                ApplicationException.ShareConnection.ExecuteScalar(
                    "SELECT Id FROM TaxGroup WHERE TaxGroup.IsDefault");

            Application.ShareConnection.ExecuteNonQuery(
                "INSERT INTO Invoice (CustomerId, EffectiveDate) VALUES(?,?)",
                 customer.Tables[0].Rows[0]["Id"], System.DateTime.Now);

            int invoiceId;

            invoiceId = Application.SharedConnection.ExecuteScalar("SELECT @@IDENTITY");

            Application.SharedConnection.ExecuteNonQuery(
                "INSERT INTO InvoiceLine (ProductId, Quantity, InvoiceId) VALUES(?,?,?)", ,
                order.Tables[0].Rows[0]["ProductId"], order.Tables[0].Rows[0]["Quantity"], invoiceId);

            foreach(string mail in mails.Split(';'))
            {
                Application.MailSender.Send(mail);
            }

            isValid = true;

            System.Data.DataRow row = invoice.Tables[0].NewRow();
            row["Id"] = invoiceId;

            invoice.Tables[0].Rows.Add(row);

            return invoice;
        }
    }
}

正如你所看到的，这里有很多糟糕的代码。

重构后，方法将不再是静态的，ref参数将被删除，DataSet将被转换为POCOs对象，对“Application”等全局对象的访问将被动态注入的属性取代，并且将进行许多其他更改，如实现接口，回顾类的名称、命名空间和许多其他东西。事实上，这段代码完全是一个垃圾，应该扔掉并从头开始重写。

如果我为原始静态方法创建单元测试，则当删除 static 关键字以以更面向对象的方式使用该类时，测试将立即中断。将 DataSet 更改为 Poco 等也是如此……

如果 5 分钟后我会扔掉这个测试，为什么要创建一个单元测试呢？这次测试有什么帮助？

在这种情况下你会使用哪种策略？

非常感谢。

Answer 1

这里的关键是选择您实际上要进行单元测试的点。就您而言，对您要替换的确切方法进行测试是没有意义的。相反，需要为应用程序中调用您的方法的每个点创建测试，以确保特定功能仍然正常工作。

原因是，一旦完成 DataCreator 类的重构，您将必须返回到调用它的所有区域并更改它们。在进行更改之前对这些区域进行测试将确保您的功能相同。

请参见下文：

public class SomeClass {
  public Boolean DoSomething() {
    OtherClass oc = new OtherClass();
    return oc.DoSomethingElse("param1", "param2") == "true";
  }
}


public class OtherClass {
  public String DoSomethingElse(String param1, String param2) {
      // horrible code here which never uses the second parameter

     return "true";
  }
}

在上面的示例中，您可能非常希望重构 DoSomethingElse 以将返回类型更改为布尔值并消除第二个参数。

因此，您首先对 SomeClass.DoSomething 方法进行单元测试。然后将 OtherClass 重构为您心中的内容，确保 DoSomething 的最终结果是相同的。

当然，在这种情况下，您需要确保对调用“DoSomethingElse”的每个事物都进行单元测试。

Answer 2

您的单元测试始终必须随着签名的更改而更改。解决这个问题的最佳方法是设置单元测试来测试一般行为，并首先进行简单的优化。

例如，从优化函数代码本身开始（例如，修复数据访问并将函数分成几个函数。）

然后您可以进行签名重构，但在此之前，请确保使用此函数的组件类具有基本的预期结果测试，因此您知道在删除 out 参数的过程中是否忽略了依赖于此的类之一中的某些内容。

当进行重大重构时，您的测试将会发生很大的变化。有时，布置概念测试就足够了，这样您就可以确保通过重构，可用性是相似的，或者您将知道哪些测试已被弃用，哪些测试需要在许多其他依赖类中进行更新。

Answer 3

按照您想要的方式编写接口，并针对该接口编写单元测试。

然后从接口调用遗留代码，直到测试通过。

然后根据需要进行重构。

正确的？

Answer 4

在开始更改方法之前，单元测试将作为该方法需要/执行哪些功能的活动/实时记录。

将它们视为检查表，供您在重构方法后进行思考，以确保它仍然涵盖重构之前所涵盖的内容。