我是否需要单元测试此功能？

我一直在研究很多关于单元测试的知识，我有几个函数，其唯一目的是根据模型中的用户输入添加或更新数据库中的行。从我读过的内容来看，单元测试似乎并没有真正用于此。集成测试可能更有意义，但我还没有对这些进行过多研究。我很抱歉，如果这是其他地方，我试图找到一个类似的例子，这个问题是我能找到的最接近的：https://softwareengineering.stackexchange.com/questions/198453/is-there-a-point-to-unit-tests-that-stub-and-mock-everything-public ...这意味着单元测试不是测试函数的最佳方式，只是调用数据库。我是否需要单元测试此功能？

这里是我们的数据库功能中的一个例子...

public void AddDependant(AddDependantView addDependantView, int ID) 
    { 
     using (var db = new EnrollmentDataModel()) 
     { 
      Dependant dependant = new dependant(); 
      dependant.ID = ID; 
      dependant.FirstName = addDependantView.FirstName; 
      dependant.LastName = addDependantView.LastName; 
      dependant.Relation = addDependantView.Relation; 
      dependant.Birthday = (addDependantView.BirthDate).Value.ToString("MM/dd/yyyy"); 
      dependant.Active = true; 
      dependant.RowCreatedDateTime = DateTime.Now; 

      db.Dependant.Add(dependant); 
      db.SaveChanges(); 

      UpdateLog(ID, "Dependant Data Added", "User added their dependant data."); 
     } 
    }

的“UpdateLog”函数调用结束时在结构上这一个相似，但增加了该记录任何一个不同的数据库中的条目用户活动。

那么这个函数会受益于单元测试吗？如果它确实会有什么好处？整合测试会是更好的选择吗？如果这太基本或太宽泛，我很抱歉，但对于单元测试我很新，希望进入良好实践。

来源

2016-09-06 LittleBachman

根据定义，这不是一个单元测试，而是一个集成测试，因为它具有一个外部依赖性，该属性被内化到该方法。如果你想单元测试这个，你需要做一个模拟数据存储注入方法/类，而不是在方法中创建一个新的上下文。对此的看法各不相同......特别是因为Linq 2 Sql无法处理的大量操作在模拟单元测试中不会失败，而他们在集成测试中会失败。 –

由于它在内部创建数据库上下文，因此无法对此函数进行单元测试。你想在这里测试什么？ SQL查询？你只能写集成测试。 – tym32167

要在最后回答您的问题，此功能将从集成测试中受益更多。从单元测试这个函数中获得的好处主要是通知代码中的某些内容何时发生变化。

例如，在模拟/间谍/存根中，您可以编写测试来声明此函数可以进行正确的db api调用。这些电话会得到正确的论点。然而，如果你的模拟与真实事物不同步，那么这些测试可以作为单元测试通过，并且在集成测试中仍然失败。

你可以在这里单元测试的最好部分是dependent对象。声明它有一个ID，名字，姓氏等等......然后如果你的生产代码曾经改变过，说其中一个属性被意外删除了。你的单元测试会让你知道比集成测试更快的速度。

这里的缺点是，你更有可能改变目的，然后在意外。这些单元测试可能会变得令人讨厌，因为它们每次改变都会失败。

所以这是有利和不利的。这个好处是否值得这个麻烦取决于你。我认为大多数人会同意，但对于像这样的功能，集成测试就是你真正需要的。

来源

2016-09-06 19:19:54

我是否需要单元测试此功能？

回答

相关问题