代码之家  ›  专栏  ›  技术社区  ›  Dan Ling

这个单元测试是否过度?

  •  1
  • Dan Ling  · 技术社区  · 15 年前

    **编辑2:实际上,这个类将实现一个IMapper接口,并且在应用程序的业务逻辑层将进行全面的行为(mock)测试。这个测试恰好是必须基于状态的最低级别的测试。我怀疑这个测试是否真的有必要,因为测试代码与源代码本身几乎相同,并且根据实际经验,我不知道这个单元测试如何使应用程序的维护变得更容易。

    //SUT
    public class Mapper
    {
      public void Map(DataContract from, DataObject to)
      {
        to.Value1 = from.Value1;
        to.Value2 = from.Value2;
        ....
        to.Value100 = from.Value100;
      }
    }
    
    //Unit Test
    public class MapperTest()
    {
       DataContract contract = new DataContract(){... } ;
       DataObject do = new DataObject(){...};
       Mapper mapper = new Mapper();
       mapper.Map(contract, do);
       Assert.AreEqual(do.Value1, contract.Value1);
       ...
       Assert.AreEqual(do.Value100, contract.Value100);
    
    }
    
    6 回复  |  直到 15 年前
        1
  •  3
  •   Steven A. Lowe    15 年前

    我会质疑构造本身,而不是测试它的必要性

        2
  •  3
  •   kÍ©eÍ£mÍ®pÍ¥ Í© Sitam Jana    15 年前

    然而,最好是100个单独的单元测试,每个测试检查一个值。 那样的话,当你出了问题 value65 ,您可以运行测试,并立即找到 价值65 value66

    但是,如果您有一个100个属性都命名为ValueXXX的类,那么最好使用数组或列表。

        3
  •  2
  •   Paxic    15 年前

    "Under the strict definition, for QA purposes, the failure of a UnitTest implicates only one unit. You know exactly where to search to find the bug."

    单元测试的威力在于拥有一个已知正确的结果状态,重点应该是分配给DataContract的值。这就是我们想要推动的界限。确保DataContract的所有可能值都能成功复制到DataObject中。必须使用边缘大小写值填充DataContract。

    David Kemp是对的,100个设计良好的测试将是单元测试概念中最真实的测试。

    对于这个测试,我们必须假设DataContract在构建时完全填充(这需要单独的测试)。

        4
  •  2
  •   RickL    15 年前

        5
  •  0
  •   Morendil    15 年前

    如果这是整个应用程序中唯一的此类单元测试,则不会。然而,当另一个类似的场景出现时,你会看到我皱起眉毛,开始思考反射。

        6
  •  0
  •   webclimber    15 年前

    我同意代码看起来很奇怪,但上面说:

    单元测试的美妙之处在于,一旦完成就永远存在,因此,如果任何人出于任何原因决定更改该实现以获得更“聪明”的东西,那么测试应该通过,所以这不是什么大问题。