将home-brew测试应用程序转换为标准单元测试框架

时间:2008-10-08 00:21:29

标签: c# unit-testing automated-tests homebrew

我已经为一个软件编写了大量测试(这是一件很棒的事情),但它基本上是作为C#中的独立测试而构建的。虽然这种方法运行良好,但它有一些缺点,其中最重要的是它没有使用标准测试框架,最终要求运行测试的人注释掉不应该运行的测试的调用(当不希望运行整个测试'套件'时)。我想将它纳入我的自动化测试过程。

我看到VS 2008的测试版有一个'通用测试'的概念可能会做我想要的,但我们目前无法在这个版本上花钱。我最近开始使用VS 2008 Pro版本。

这些测试方法遵循熟悉的模式:

  • 为测试做一些设置。
  • 执行测试。
  • 重置以进行下一次测试。

每个人都返回一个bool(通过/失败)和一个字符串引用失败的原因,如果失败则填入。

从好的方面来看,至少测试方法是一致的。

我今晚坐在这里考虑明天早上可能采取的方法将所有这些测试代码迁移到测试框架,坦率地说,我对于研究8-9K行测试代码的想法并不是那么兴奋用手做转换。

您是否有过进行此类转换的经验?你有什么建议吗?我想我可能会陷入困境,全都在进行全局搜索/替换并手动更改测试。

有什么想法吗?

2 个答案:

答案 0 :(得分:4)

如果您使用NUnit(您应该使用),则需要为每个当前测试方法创建一个新的测试方法。 NUnit使用反射来查询测试类以查找标有[Test]属性的方法,该属性是如何构建其在UI中显示的测试列表,测试类使用NUnit Assert方法表明他们是否通过了。

在我看来,如果你的测试方法与你说的一致,那么所有这些NUnit方法都会是这样的:

[Test]
public void MyTest()
{
   string msg;
   bool result = OldTestClass.MyTest(out msg);
   if (!result)
   {
      Console.WriteLine(msg);
   }
   Assert.AreEqual(result, true);

}

一旦你开始工作,你的下一步就是编写一个程序,使用反射来获取旧测试类中的所有测试方法名称,并生成一个.cs文件,该文件对每个原始文件都有一个NUnit方法测试方法。

烦人,也许,但不是非常痛苦。你只需要做一次。

答案 1 :(得分:1)

你将要通过“一瞥预防值得一磅治疗”的成语来生活。在编程中尤其如此。

你没有提到NUnit(我认为它是微软2008年购买的,但不要让我这么做)。你是不是首先使用NUnit?