我的公司刚刚开始在一个不断增强的遗留系统上进行单元测试( system )。
该系统是以核心功能构建的,开发人员正在开发新的功能(通过添加新的类库),并通过接口与核心系统集成,例如从核心函数的基础上重写或实现方法。我们开发的每个类库都有一个标准方法ProcessRequest,并且是一个受保护的覆盖方法,它有一些代码来进行处理,例如调用外部web服务提供者、分配响应对象等等。
但是,在每个单独的类库中,可能/可能没有实用函数方法,如ConvertValue()、AssignValueToObject()方法等。
正如我们在激烈的争论/讨论中提出的那样,有一小群开发人员建议我们只测试实用程序函数方法(即ConvertValue()、AssignValueToObject()),而忽略了在受保护的覆盖ProcessRequest()方法中测试代码的必要性,并建议我们只测试ProcessRequest ()异常处理。
然而,即使在ProcessRequest()方法中,也有一些同事支持测试。
我的领导还说,测试ProcessRequest()是“太高水平”,但我认为单元测试应该从新特性的切入点进行。
请提供关于单元测试入门最佳实践点的建议,这是行业/开发文化中的实践。
注:-
ProcessRequest()上有一些易发生变化的情况,供应商可能会更改他们的WS端点,这是我们需要更改的,我们的ProcessRequest()上也需要更新。ProcessRequest()中。发布于 2015-11-26 07:02:10
在遗留代码上编写单元测试是一项艰巨的任务。由于您刚刚开始实现单元测试,所以最好先简单地开始,然后在您正在开发的新模块上。稍后,您可以将所学的内容应用于旧模块。
代码应该以允许单元测试的方式进行。主要而言,要测试的类应该支持模拟,不属于当前类的外部组件/类应该从接口派生出来。这样,您就可以只进行单元测试,或者对所有相关组件进行集成测试。
为了使它具有可测试性,您可能需要接触所有相关的类并重写它们,以便它可以测试。除非你有测试工具,否则任何改变都将是一个突破性的改变。如果您是新的单元测试,您需要舒适地编写符合您的项目的单元测试。
如果您从新创建的组件开始,这将更好。然后,您可以对实践有信心,然后可以将这些知识应用到遗留代码上。
当您对在特定类中编写单元测试的方法感到困惑时,可以遵循以下两点。
发布于 2015-11-30 05:54:47
这就是有用的遗留系统的特点。它们非常有用,人们希望将它们保存在身边,即使用户的需求以及他们所处的平台和中间件环境发生了变化。
由于这个原因--现在和将来系统都会发生变化--单元测试应该主要而且几乎完全涉及类和对象的黑箱测试。
对象内部的白盒测试意味着每次重构代码或更改系统功能时,测试都会中断。这使得
以下是您需要进行单元测试的内容:
传入消息的断言--用于查询和命令消息。
断言应该仅仅是每个边界条件的任何一方,也应该是可接受数据范围内的一个中点。(对于对一系列整数起作用的方法,每个方法=5个断言)
因此,在类的协议中,每个有效的传入消息有一组5个断言。
对传出命令消息的期望,使用一个Mock对象,该对象具有与其发送的活动对象的消息协议相匹配的消息协议。
(命令消息是改变属性状态的消息,也称为副作用)。
其他测试没有显示任何有用的东西和/或太脆弱,需要大量的努力来创建和维护。
这里有一个非常有说服力的讨论视频,正是这个主题,并给出了Ruby中的代码示例。
发布于 2016-02-15 23:20:30
听起来你的公司实际上正在用一个单元测试框架进行大量的集成测试,在你的例子中,就是MS测试。这种做法绝对没有错。然而,我经常观察到,当对单元测试没有明确的理解时,关于单元测试的讨论就会走向错误的方向。
有很多资源解释什么是单元测试。简而言之,在面向对象的语言中,它是对一个依赖尽可能少的方法的测试。
我怀疑代码库由相当大的类组成,其中包含一个调用私有或内部实用程序方法的ProcessRequest()方法。在这种情况下(以及您描述的因素),测试这些实用程序方法更接近于单元测试。你应该有很多。测试ProcessRequest()方法更接近于集成测试,在许多单元测试的基础上,您应该有一些具有代表性的方法。
https://sqa.stackexchange.com/questions/15824
复制相似问题