能否通过注解的方式去实现单元测试呢?

本贴最后更新于 1975 天前,其中的信息可能已经时过境迁

起因

单元测试在项目中的作用不言而喻,但是写单元测试、改了逻辑以后改单元测试,却也是比较烦人的

目前有很多的测试框架 比如 mockito 、easyMock 、powerMock 等,都已经帮助开发者解决了很多测试的难题,但是单元测试还是得自己写代码。

我就想知道目前有没有可以不用自己写太多代码,在运行的时候,去自动化测试的呢?

现在不是都有插件可以省去 get 、set 方法了嘛 ~

我的想法

  • 单元测试编写:
    直接省去,在需要测试的方法上加注解 比如 @WillTest, 同时也可以参数传入 需要 mock 的对象(借助于 powerMock 之类的 去 mock 对象出来),甚至可以再加一个注解,用于传入多个 用例

  • 测试:
    在项目打包、启动的时候,通过反射进行单元测试、覆盖大部分简单的测试,至于复杂逻辑 可以支持手写 powerMock 测试类……

问题

  • 需求: 是否会存在这样的需求? 对于我来讲,如果有那是再好不过了
  • 有没有: 目前是否已经有类似的东西出来了?
  • 可行性: 如果有这个需求,目前还没有,自己去实现的话,可是实现吗?在测试逻辑的时候,存在那些难点,哪部分是水比较深的呢?

如果有这么个玩意,你会喜欢吗

单选 公开 永不结束 10 票
卧槽,好东西啊
80% 8 票
无所谓,反正我也不做单元测试
10% 1 票
不用,什么垃圾玩意
10% 1 票
先看看别人用的好不好 了
0% 0 票

  • Java

    Java 是一种可以撰写跨平台应用软件的面向对象的程序设计语言,是由 Sun Microsystems 公司于 1995 年 5 月推出的。Java 技术具有卓越的通用性、高效性、平台移植性和安全性。

    3190 引用 • 8214 回帖 • 1 关注
  • 自动化测试
    20 引用 • 30 回帖 • 1 关注
  • Q&A

    提问之前请先看《提问的智慧》,好的问题比好的答案更有价值。

    8449 引用 • 38491 回帖 • 155 关注

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • someone9891 2 评论

    @participants 开始着手尝试了, 但是无从下手啊,目前还只是停留在概念的阶段。。各位有没有好的建议 或者 见过的类似的东西分享让我学习下,最近工作也比较忙,都是晚上简单构思一会。
    目前的进度:

    • 构思:

      • 注解: 目前暂有两个注解;一个标明需要被测试(考虑传入用例)、还有一个注解用于 标明 Mock 的 对象,该注解加载成员变量上或者方法上。
      • 配置:提供 xml、yml、java 类等配置方法,配置主要内容 如 需要扫描的包路径、全局的用例、全局常量等。
      • 实现:在项目编译的时候扫描配置的包路径 检查注解,然后开始 mock 并测试,必要的时候 学习 powermock 之类的直接通过 cglib 派生子类 或者 直接 修改字节码。
    • 计划

    目前在本地做了尝试,计划在多少有点眉目的时候将代码放到 Github 上,接受广大人民群众的 测试于贡献。

    但是—— 无从下手啊,只是试了一下 配置和扫描的,具体测试部分的逻辑我觉得没有想象中的那么简单。大家都多给点建议,无论是设计、实现以及功能上,都可以。

    还有一点,就是一般的单元测试都是可以单个方法手动执行的,如果是声明式的,那么想要实现单个非 main 方法直接执行的话,是否 还得去开发 idea 和 eclipse 的插件呢?

    我大概了解了一下,junit 好像就是 靠的插件 最终还是通过 main 方法去执行的,测试。
    大家畅所欲言吧,提意见、吐槽、泼冷水都是没问题的

    1 回复
    @88250 刚才说什么安全异常是什么鬼
    someone9891
    @gitors 可能是 CSRF token 过期了,刷新重试即可
    88250
  • 其他回帖
  • PeterChu

    好像很厉害的样子哇。
    单元测试还是很必要的,可能一些简单逻辑的增删改查用不用单元测试都一样,一些比较复杂逻辑的单元测试恐怕不太好用自动化工具去测,但是介于这两者之间的很多业务逻辑的单元测试还是有很多,也应该可以使用非人工测试完成,这样却是会节省很多时间和工作量啊。
    期待期待。

  • 这样的需求在绝大多数场景下都不是很适用。业务逻辑应该和测试逻辑分开的,比如在多数 java 的 web 项目中,业务代码都放在 main 目录下,测试都放在 test 目录下。如果通过注解来辅助测试,业务代码中会不可避免的多出来很多测试逻辑。试想一下每个 service 方法上面都有 @MockWith(...) @AssertThat(...) 之类的东西,代码的可读性会下降多少。

    2 回复
  • PeterChu

    @gitors 你有阿里出的《码出高效-JAVA 开发手册》这个书吗,可以看看这里第 8 章,写的更详细点。需要电子版资源我可以给你发。
    image.png

    1 回复
  • 查看全部回帖