博客

修改 JUnit 5 的方法和类可见性

December 21, 2020
Alan Richardson

修改 JUnit 5 的方法和类可见性

编程的乐趣之一在于需要不断学习以保持与时俱进。但问题在于,我们容易形成固有的使用习惯和模式,这可能会影响对新方法的采纳。Sensei 可以通过识别弃用的模式并提示我们后续应使用的修复方案,从而助力迁移过程。

例如,当我从 JUnit 4 迁移到 JUnit 5 时,我习惯将所有的测试类和方法都写成 public。但在 JUnit 5 中,它们可以是包私有(package private)的。

例如,与其这样写:

public class Junit5VisibilityTest {
    @Test
    public void thisDoesNotNeedToBePublic(){
        Assertions.assertTrue(true);
    }
}


我更希望这样写:

class Junit5VisibilityTest {
    @Test
    void thisDoesNotNeedToBePublic(){
        Assertions.assertTrue(true);
    }
}


我花了一段时间才养成这种编码的肌肉记忆,而且偶尔还是会出错。

使用 Sensei

借助 Sensei,我可以创建配方来查找 public 方法和类,并自动将声明修改为包私有。

为了实现这一点,我创建了一个配方:

名称 - JUnit:JUnit 5 测试方法无需设为 public
描述 - JUnit 5 测试方法不需要 public 可见性
级别 - 错误


我将其归类为“错误”,因为我想杜绝这种编码习惯,并且希望在 IDE 中编写代码时能更直观地发现这个问题。

修改类声明

为了查找这些类,我搜索所有包含 JUnit 5 的 @Test 子注解(即 org.junit.jupiter.api.Test)的类。

并且针对那些具有 public 修饰符的类:

搜索:
  类:
    包含:
      子项:
        注解:
          类型: "org.junit.jupiter.api.Test"
    修饰符: "public"

随后,快速修复功能会修改修饰符以移除可见性,使其变为默认状态。默认状态即包私有(package private),这正是我所需要的。

可用修复:
- 名称: "移除 JUnit 5 测试类的 public 可见性"
  操作:
  - 修改修饰符:
      可见性: ""



修改方法声明

修改方法声明的配方与修改类的配方基本相同。

首先,我搜索带有 JUnit 5 @Test 注解的 public 方法。

搜索:
  方法:
    注解:
      类型: "org.junit.jupiter.api.Test"
    修饰符: "public"


然后,我将修饰符更改为默认可见性。

可用修复:
- 名称: "移除 @Test 方法的 public 可见性"
  操作:
  - 修改修饰符:
      可见性: ""


提示:修改多个方法

Sensei 能够将快速修复应用于当前文件中的所有违规项。

当我使用 alt+enter 应用快速修复时。

如果我展开快速修复名称菜单,可以看到一个选项:

"修复全部:文件中的 'JUnit: JUnit 5 测试方法无需为 public' 问题"

当我选择该选项时,Sensei 将修改所有出现该问题的地方,而不仅仅是我选中的那一个。


Remove Test Method Public Visibility

修改类

与方法无需为 public 一样,类也不需要。

我可以创建一个配方和一个快速修复来修改类。

名称 - JUnit: JUnit 5 测试类无需为 public
描述 - JUnit 5 测试类无需为 public
级别 - 错误


当我找到一个 public 类且其中包含带有 @Test 注解的方法时,我希望更改其可见性。

搜索:
  类:
    修饰符:"public"
    anyOf:
    - 子项:
        方法:
          注解:
            类型:"Test"


我可以再次使用 changeModifiers 操作来修改类定义。

可用修复:
- 名称:"移除 @Test 类的 public 可见性"
  操作:  
- changeModifiers:
      可见性:""


总结

最初是静态分析工具提醒我 JUnit 有这种推荐做法。但该工具无法帮我在编程时建立起修改代码的肌肉记忆。

利用“级别”来提醒自己。当我试图在编码中根除某个问题时,我会先将其设为“错误”,随着我逐渐改掉这种编码习惯,再降低其级别。

请记住,在使用快速修复(QuickFix)时,你可以通过下拉菜单选项,一次性修复当前文件中的所有问题。

通过创建 Sensei 配方,我可以实时看到自己旧的编码方式。如果偶尔出现疏忽,还能通过快速修复来强化正确的编码习惯。

---

你可以直接在 IntelliJ 中安装 Sensei:通过“偏好设置 > 插件”(Mac)或“设置 > 插件”(Windows),然后搜索“sensei secure code”即可。

本示例的源代码和配方可以在 Secure Code Warrior GitHub 账号下的 `sensei-blog-examples` 仓库中的 `junitexamples` 模块中找到。



标语

在 AI 驱动的开发成果发布前实现有效治理

评估 AI 辅助风险,在提交代码时强制执行安全编码策略,并加速整个软件开发生命周期的安全交付。

预约演示
资源库

探索更多博客

获取有关安全编码、人工智能治理和软件风险管理的专家内容。

浏览全部
案例研究
筛选标签
这是 div 块中的一段文本。

Supercharged Security Awareness: How Tournaments are Inspiring Developers at Erste Group

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

了解更多
案例研究
筛选标签
这是 div 块中的一段文本。

Security as culture: How Blue Prism cultivates world-class secure developers

Learn how Blue Prism, the global leader in intelligent automation for the enterprise, used Secure Code Warrior's agile learning platform to create a security-first culture with their developers, achieve their business goals, and ship secure code at speed

了解更多
案例研究
筛选标签
这是 div 块中的一段文本。

统一的安全文化:Sage 如何打造其安全倡导者项目

了解 Sage 如何通过灵活且以关系为导向的方法提升安全性,成功培养了 200 多名安全倡导者,并实现了显著的风险降低。

了解更多
博客
筛选标签
这是 div 块中的一段文本。

2026年网络安全意识月:理解人工智能安全对企业防御至关重要

目前,大多数顶级人工智能公司已公开呼吁全球放缓人工智能的发展速度,以便安全防护措施能够跟上步伐。然而事实是,严重的安全问题已经显现。随着人工智能实施带来的经济成本和风险不断累积,无数安全领导者和高管团队正处于紧迫的境地。

了解更多
博客
筛选标签
这是 div 块中的一段文本。

赋能要素 8:打造项目品牌

成功的安全编码项目不仅需要优质的内容。赋能要素 8 展示了如何通过品牌化将参与过程转变为一种令人向往、以地位为驱动的体验。

了解更多
博客
筛选标签
这是 div 块中的一段文本。

每一位员工现在都处于 AI 网络安全的最前线

企业技术格局正以一种鲜有人预料到的速度发生剧变,直到为时已晚。我们已正式跨越了从人工编写代码和基础辅助编程,进入“智能体开发生命周期”(ADLC)的时代。虽然自主 AI 智能体有望在多个职能领域实现前所未有的效率,但它们也带来了全新的安全和监管风险。

了解更多

在产品发布前确保 AI 驱动的开发安全

洞察开发风险,执行安全策略,并在整个软件开发生命周期中预防漏洞。

预约演示
未找到相关项目。