【问题标题】:Is there any value in using abstract test classes ro run Unit and Integration testing?使用抽象测试类来运行单元和集成测试有什么价值吗?
【发布时间】:2009-10-14 05:45:39
【问题描述】:

我有这个抽象测试类

[TestFixture]
public abstract class BaseTests
{

       private IRepository _repository;

        public BaseTests(IRepository repository)
        {
            _repository = repository;
        }

        [Test]
        public virtual void CanGetResultsFromSearch()
        {
            var results = _repository.GetResults("test");
            Assert.IsTrue(results.Count() > 0);
        }
}

执行基本测试作为单元测试和集成测试的一部分是否有任何价值。例如

[TestFixture]
public class UnitTest : BaseTests
{
    private static IRepository _repository = new FakeReposistory();

    public UnitTest() : base(_repository)
    {
    } 
}

[TestFixture]
public class IntegrationTest : BaseTests
{
    private static IRepository _repository = new SqlReposistory();

    public UnitTest() : base(_repository)
    {
    } 
}

重复测试两次是否有价值?我有点不清楚这个特定的测试是否是集成测试的关注点?即集成测试是否应该在类上测试公共方法?还是应该更多地测试系统的功能?还是两者都有?!

【问题讨论】:

    标签: c# unit-testing testing integration-testing


    【解决方案1】:

    在编写您的示例时,运行两个测试套件绝对是有意义的,因为它们将测试两个不同的东西。

    在第一种情况下,它会针对假数据库测试您的被测系统 (SUT)。

    在第二种情况下,它会针对真实数据库测试您的 SUT。

    至少,这些测试将验证 SUT 不违反 Liskov 替换原则。

    但还有其他优点:您的产品可能不会在生产环境中针对 Fake 数据库运行,因此集成测试可以更好地指示代码是否按预期工作。但是,运行集成测试可能会比运行单元测试套件慢得多,因此即使单元测试套件不是一个真实的场景,它也会为您提供有关代码状态的更快速反馈。

    【讨论】:

      【解决方案2】:

      我是那种认为可以将一个单元扩展为包含数据库的邪恶分子,所以请谨慎对待任何其他怪人。

      在大多数情况下,我认为重复测试甚至使用完全模拟的数据库在数据层上运行单元测试是没有意义的(一个例外是错误情况)。

      您介意我问GetResultsFakeReposistory 的影响吗?或者这是一种简化,真的是new SqlReposistory(mockedConnection)

      【讨论】:

      • 这只是一个例子,但理论上它可以执行搜索并返回一个 List
      • 但是看起来仍然是你没有在存储库上运行单元测试,而是在 FakeReposistory 上运行。哪个(对我来说)毫无意义,因为 FakeReposistory 就是这样 - 你可以控制单元测试的东西。
      猜你喜欢
      • 2010-10-27
      • 2011-12-25
      • 1970-01-01
      • 2011-07-18
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2015-09-05
      相关资源
      最近更新 更多