【问题标题】:What are some of IdeaBlade's limitations?IdeaBlade 有哪些限制?
【发布时间】:2011-02-12 08:38:22
【问题描述】:

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

谢谢, 亚历克斯

【问题讨论】:

    标签: wpf silverlight tdd devforce


    【解决方案1】:

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

    它可以测试吗?对此,我可以以答案的开头来回应。

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

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

    2) 您可以使用任何您喜欢的 ctor 来新建这样的实体,并且无需其他设置即可获取和设置其(非导航)属性。

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

    当然需要程序集引用。

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

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

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

    现在 order.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 继承(你必须)贡献了另外五个无关紧要的东西。

    我们认为我们在纯 P.I.并且易于开发。

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

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

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

    希望对你有帮助

    病房

    【讨论】:

    • 感谢您的回答,它非常好,它说服了我至少对产品进行评估。否则我不会这样做,因为我已经训练自己忽略流行语,并且它的描述主要是流行语。我最担心的是它可能缺乏灵活性。我喜欢端到端地测试“有趣的功能”。当这不可能时,我会定义一些界限,以便清楚“结束”。在过去的几个月里,在一个智能客户端上工作,边界是 GUI 和数据层(由于测试 EF 的复杂性),但我正在研究白色项目以将边界推向 WPF GUI。
    猜你喜欢
    • 2014-12-25
    • 2011-01-26
    • 1970-01-01
    • 1970-01-01
    • 2012-03-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多