3

我将启动一个需要 Web 和桌面界面的项目。一种解决方案似乎是 IdeaBlade ( http://www.ideablade.com )。任何使用它的人都可以描述它的局限性和优势吗？可以测试吗？

谢谢，亚历克斯

4

1 回答 1

6

作为 IdeaBlade 的技术副总裁，我不能对 DevForce 在这个领域的限制和优势发表一般性评论。不过很高兴回答具体问题。

可以测试吗？对此，我可以用答案的开头来回应。

这是一个潜在的有争议的问题。人们对是什么使某物可测试有强烈的感觉。让我将自己限制在特定的测试场景......然后您判断我们满足您的测试要求的程度。

1) 如果您愿意，DevForce 支持纯 POCO 实体。大多数人会更喜欢使用派生自我们的基 Entity 类的实体，因此我将后续的评论完全限制在这些实体上。

2）您可以使用任何您喜欢的 ctor 来新建这样的实体，并在没有其他设置的情况下获取和设置其（非导航）属性。

var cust = new Customer {ID=..., Name =...}; // have fun

当然，汇编引用是必需的。

3) 要测试它的导航属性（返回其他实体的属性），首先新建一个 EntityManager（我们的工作单元，类似上下文的容器），将实体添加或附加到 EM，然后离开。从我们的基类继承的实体的导航属性期望通过该容器找到相关实体。

4) 在大多数自动化测试中，EntityManager 将在断开连接状态下创建，因此它永远不会尝试访问服务器或数据库。

您可以向它添加一个订单、一个客户、一些 OrderDetails；请注意，所有这些都是在您的测试上下文中构建的......不是从任何地方检索到的。

现在 order.Customer 返回测试 Customer；order.OrderDetails 返回您的测试详细信息。您的准备工作包括创建 EM、测试实体，确保这些实体具有唯一的 ID 并关联。

这是一个示例序列：

var mgr = new EntityManager(false); // create disconnected

var order = new Order {ID = ..., Quantity = 1, ...};

var customer = new Customer {ID = 42, Name = "ABC", };

mgr.AttachEntity(order);

mgr.AttachEntity(customer);

order.Customer = customer; // associate them

EM 充当内存数据库。

5) 你现在可以使用 LINQ

var custs = mgr.Customers.Where(c => c.Name.StartsWith("A").ToList();

var orders = mgr.Orders.Where(o => o.Customer.Name.StartsWith("A")).ToList();

6）当然，我总是在每次测试之前创建一个新的EntityManager，以消除交叉测试污染。

7) 我经常编写一个所谓的“Data Mother”测试助手类，用标准的测试数据集合填充 EM，包括异常案例。

8) 我可以将 EntityManager 的测试实体缓存导出到文件或测试项目资源。当测试运行时，DataMother 可以检索和恢复这些测试实体。

请注意，我正逐渐从单元测试转向集成测试。但是（到目前为止）我的测试不需要访问服务器、实体框架或数据库。它们运行速度快，不易受到分散设置故障的影响。

当然，您可以在深度集成测试中访问服务器，并且可以轻松地为本地、LAN 和 Web 场景动态切换服务器和数据库。

9) 可以拦截查询、保存、更改、添加、删除等事件进行交互测试。

10) 我所描述的一切都适用于常规的 .NET 和 Silverlight 以及我遇到的每个测试框架。

不利的一面是，我不会将我们的产品描述为对模拟友好。

我欣然承认，我们不是坚持无知（PI）。如果您是 PI 狂热者，那么我们是您的错误选择。

我们试图了解 PI 的重要优势，并尽最大努力在我们的产品中实现它们。我们尽我们所能将框架问题排除在外。尽管如此，如您所见，我们的抽象在一些地方仍然存在漏洞。例如，我们将这些成员添加到您实体的公共 API：

  • EntityAspect（通向持久性意识的门户）
  • 错误已更改
  • PendingEntityResolved
  • 属性已更改
  • 查询<>

就个人而言，我会将其减少到两个（EntityAspect，PropertyChanged）；其他人从我身边偷偷溜走。对于它的价值，从 Object 继承（你必须）贡献了另外五个无关紧要的东西。

我们觉得我们在纯 PI 和易于开发之间做出了很好的权衡。

我的问题是“它是否为您提供了在没有太多摩擦的情况下验证期望所需的东西……从单元测试到深度集成测试的整个范围？”

我当然很想知道您如何获得与类似产品摩擦较少的类似设施。并渴望就我们如何改进对应用程序测试的支持提出建议。

请随时跟进有关我可能忽略的其他测试场景的问题。

希望这可以帮助

病房

于 2010-04-29T01:37:05.863 回答