首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >单元测试入口点的最佳实践

单元测试入口点的最佳实践
EN

Stack Exchange QA用户
提问于 2015-11-26 06:44:39
回答 3查看 1.1K关注 0票数 4

我的公司刚刚开始在一个不断增强的遗留系统上进行单元测试( system )。

该系统是以核心功能构建的,开发人员正在开发新的功能(通过添加新的类库),并通过接口与核心系统集成,例如从核心函数的基础上重写或实现方法。我们开发的每个类库都有一个标准方法ProcessRequest,并且是一个受保护的覆盖方法,它有一些代码来进行处理,例如调用外部web服务提供者、分配响应对象等等。

但是,在每个单独的类库中,可能/可能没有实用函数方法,如ConvertValue()AssignValueToObject()方法等。

正如我们在激烈的争论/讨论中提出的那样,有一小群开发人员建议我们只测试实用程序函数方法(即ConvertValue()AssignValueToObject()),而忽略了在受保护的覆盖ProcessRequest()方法中测试代码的必要性,并建议我们只测试ProcessRequest ()异常处理。

然而,即使在ProcessRequest()方法中,也有一些同事支持测试。

我的领导还说,测试ProcessRequest()是“太高水平”,但我认为单元测试应该从新特性的切入点进行。

请提供关于单元测试入门最佳实践点的建议,这是行业/开发文化中的实践。

注:-

  • ProcessRequest()上有一些易发生变化的情况,供应商可能会更改他们的WS端点,这是我们需要更改的,我们的ProcessRequest()上也需要更新。
  • 大多数结果赋值代码都在ProcessRequest()中。
  • 目前不打算对遗产代码(核心系统)进行单元测试,因为它太大了,无法覆盖。在遗留代码上重构代码不是一种选择。
EN

回答 3

Stack Exchange QA用户

发布于 2015-11-26 07:02:10

在遗留代码上编写单元测试是一项艰巨的任务。由于您刚刚开始实现单元测试,所以最好先简单地开始,然后在您正在开发的新模块上。稍后,您可以将所学的内容应用于旧模块。

代码应该以允许单元测试的方式进行。主要而言,要测试的类应该支持模拟,不属于当前类的外部组件/类应该从接口派生出来。这样,您就可以只进行单元测试,或者对所有相关组件进行集成测试。

为了使它具有可测试性,您可能需要接触所有相关的类并重写它们,以便它可以测试。除非你有测试工具,否则任何改变都将是一个突破性的改变。如果您是新的单元测试,您需要舒适地编写符合您的项目的单元测试。

如果您从新创建的组件开始,这将更好。然后,您可以对实践有信心,然后可以将这些知识应用到遗留代码上。

编辑

当您对在特定类中编写单元测试的方法感到困惑时,可以遵循以下两点。

  1. 不是测试类的方法,而是测试功能。类的功能是由它的公共方法而不是它的私有方法公开的。每个公共方法都应该有自己的单元测试方法。如果您只有ProcessRequest作为公共方法,那么您的测试用例应该只处理ProcessRequest的功能--仅此而已。您应该作为局外人测试类,不应该知道私有成员/私有方法。您应该只测试公共可见的属性和方法。作为一般规则,不要为了测试而公开成员,可能会有例外。但是功能应该是可测试的,而不需要查看类的内部状态。
  2. 方法中的每个条件分支都应该有自己的单元测试。它大致相当于if..else、switch..case、异常处理等中每个条件的测试用例.
票数 1
EN

Stack Exchange QA用户

发布于 2015-11-30 05:54:47

这就是有用的遗留系统的特点。它们非常有用,人们希望将它们保存在身边,即使用户的需求以及他们所处的平台和中间件环境发生了变化。

由于这个原因--现在和将来系统都会发生变化--单元测试应该主要而且几乎完全涉及类和对象的黑箱测试。

对象内部的白盒测试意味着每次重构代码或更改系统功能时,测试都会中断。这使得

  • 测试代码非常脆弱
  • 测试结果表明,而不是令人放心的。
  • 测试代码维护和保持与它所提供的测试服务的代码库是非常昂贵的。

以下是您需要进行单元测试的内容:

传入消息的断言--用于查询和命令消息。

断言应该仅仅是每个边界条件的任何一方,也应该是可接受数据范围内的一个中点。(对于对一系列整数起作用的方法,每个方法=5个断言)

因此,在类的协议中,每个有效的传入消息有一组5个断言。

对传出命令消息的期望,使用一个Mock对象,该对象具有与其发送的活动对象的消息协议相匹配的消息协议。

(命令消息是改变属性状态的消息,也称为副作用)。

其他测试没有显示任何有用的东西和/或太脆弱,需要大量的努力来创建和维护。

这里有一个非常有说服力的讨论视频,正是这个主题,并给出了Ruby中的代码示例。

测试中的魔术(链接)

票数 1
EN

Stack Exchange QA用户

发布于 2016-02-15 23:20:30

听起来你的公司实际上正在用一个单元测试框架进行大量的集成测试,在你的例子中,就是MS测试。这种做法绝对没有错。然而,我经常观察到,当对单元测试没有明确的理解时,关于单元测试的讨论就会走向错误的方向。

有很多资源解释什么是单元测试。简而言之,在面向对象的语言中,它是对一个依赖尽可能少的方法的测试。

我怀疑代码库由相当大的类组成,其中包含一个调用私有或内部实用程序方法的ProcessRequest()方法。在这种情况下(以及您描述的因素),测试这些实用程序方法更接近于单元测试。你应该有很多。测试ProcessRequest()方法更接近于集成测试,在许多单元测试的基础上,您应该有一些具有代表性的方法。

票数 0
EN
页面原文内容由Stack Exchange QA提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://sqa.stackexchange.com/questions/15824

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档