如何对将记录插入 RIA 服务数据库的函数进行单元测试？
这是一个与实体一起使用的示例函数，将其保存到数据库，然后会导致问题，因为我们无法为其编写单元测试。检查一下：
// this class exists in a Silverlight Class Library
public class EmployeeSaver
{
....
public void Go()
{
Employee e = new Employee();
e.Name="Jeremiah";
... // Other stuff that really needs to be tested
_DataContext.Employees.Add(e);
_DataContext.SubmitChanges();
}
}
由于 RIA 服务的性质，DomainService 不在 Silverlight 单元测试框架内运行。这意味着我在进行单元测试时无法访问 RIA。
我们考虑过模拟数据库，但此类实际上创建了一个要添加到数据库的实体（员工）。这是有问题的，因为模拟数据库不使用此实体，而是使用看起来与原始实体相似的 MockEntity 类。
我们并不是要测试 RIA 本身，而是要测试如何使用 RIA 生成的实体。
我的最终目标是编写一个与此类似的函数：
[TestMethod]
public void Test()
{
EmployeeSaver s = new EmployeeSaver();
s.Go();
Assert.IsEqual( DataContext.Employees.Last().Name, "Jeremiah" );
}
如何测试这个函数？我应该使用什么测试框架？我是否离使用 Silverlight 测试框架还很遥远？
This is a sample function that works with an entity, saves it to a db and then causes problems because we can't write a Unit Test for it. Check it out:
// this class exists in a Silverlight Class Library
public class EmployeeSaver
{
....
public void Go()
{
Employee e = new Employee();
e.Name="Jeremiah";
... // Other stuff that really needs to be tested
_DataContext.Employees.Add(e);
_DataContext.SubmitChanges();
}
}
Because the nature of RIA Services, a DomainService doesn't run inside of the Silverlight Unit Testing framework. This means I don't have access to RIA when I do my unit tests.
We've thought about mock databases, but this class actually creates an Entity (Employee) to be added to the DB. This is problematic because Mock Databases don't use this entity but a MockEntity class that looks similar to the original entity.
We're not trying to test RIA itself, but how we use the entities generated by RIA.
My end goal would be to write a function similar to this:
[TestMethod]
public void Test()
{
EmployeeSaver s = new EmployeeSaver();
s.Go();
Assert.IsEqual( DataContext.Employees.Last().Name, "Jeremiah" );
}
How can I test this function? What testing framework should I use? Am I way off for using the Silverlight Testing Framework?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在单元测试中，实例需要有一个 _DataContext 的存根实现。当Go方法被调用时，它调用：
_DataContext.Employees.Add(e);
_DataContext.SubmitChanges();
它会调用你的存根。然后，存根应该记录添加员工并提交更改的事实。
调用 Go 后，您应该查询存根以确保添加了新员工，并调用 SubmitChanges。
作为次要说明：
我不太同意另一个答案的最后部分，因为你不应该关心Go是否调用_DataContext的各种方法。确实，您不关心这里测试 _DataContext 方法，但 Go 的单元测试需要确保 Go 方法正确调用 _DataContext 方法。基本原理是 Go 方法的每一行都应该是可测试的。如果您没有进行此验证，那么您可以删除对 _DataContext 方法的调用，从而破坏代码，但单元测试不会捕获它。这将打破 Bob Martin 的“TDD 三大规则”原则。
In your unit test, instance s needs to have a stubbed out implementation of _DataContext. When the Go method is called, and it calls:
_DataContext.Employees.Add(e);
_DataContext.SubmitChanges();
it will call into your stub. The stub should then record the fact that an employee got added and changes were submitted.
After the call to Go, you should query the stub to ensure that the new employee got added, and call to SubmitChanges occurred.
As a secondary note:
I don't really agree with the last part of the other answer in that you should not care whether Go calls various methods of _DataContext. It is true that you're not concerned about testing _DataContext methods here, but the unit test for Go needs to ensure that the Go method is calling the _DataContext methods properly. The rationale is that every line of the Go method should be testable. If you didn't do this verification, then you could remove the calls to _DataContext method, breaking the code, but the unit test wouldn't catch it. This would break Bob Martin's the "three rules of TDD" principle.
手动模拟数据库可以按原样存储您的对象。我们使用这样一个系统，其中存储库存储在 .
但你甚至不需要走那么远。您可以使用 _DataContext 的模拟接口和 RhinoMocks 之类的东西来确保您期望调用的方法是（您不关心 _DataContext.SubmitChanges() 工作的测试（这将是它的单元测试） ）你只关心 Go 设置对象并调用 save。
A hand rolled mock database could store your object as is. We use such a system where the repositories are stored in dictionaries of .
You don't even need to go that far though. You could just use a mock interface for the _DataContext with something like RhinoMocks to make sure that the methods you expect to be called were (its not your concern for this test that _DataContext.SubmitChanges() works (that would be up it it's unit test) you only care that Go set the object and called save.