JUnit4用法详解

浅谈TDD

测试驱动开发,它是敏捷开发的最重要的部分。方法主要是先根据客户的需求编写测试程序,然后再编码使其通过测试。在敏捷开发实施中,开发人员主要从两个方面去理解测试驱动开发。

a)在测试的辅助下,快速实现客户需求的功能。通过编写测试用例,对客户需求的功能进行分解,并进行系统设计。我们发现从使用角度对代码的设计通常更符合后期开发的需求。可测试的要求,对代码的内聚性的提高和复用都非常有益。 
b)在测试的保护下,不断重构代码,提高代码的重用性,从而提高软件产品的质量。可见测试驱动开发实施的好坏确实极大的影响软件产品的质量,贯穿了软件开发的始终。 
在测试驱动开发中,为了保证测试的稳定性,被测代码接口的稳定性是非常重要的。否则,变化的成本就会急剧的上升。所以,自动化测试将会要求您的设计依赖于接口,而不是具体的类。进而推动设计人员重视接口的设计,体现系统的可扩展性和抗变性。 


JUnit4的用法介绍

Java 语言现在支持泛型、枚举、可变长度参数列表和注释,这些特性为可重用的框架设计带来了新的可能。
JUnit4利用 Java 5 的新特性(尤其是注释)的优势,使得单元测试比起用最初的 JUnit 来说更加简单。 

测试方法 @Test

以前所有版本的 JUnit 都使用命名约定和反射来定位测试。例如,下面的代码测试 1 + 1 等于 2:

 

import  junit.framework.TestCase;
public   class  AdditionTest  extends  TestCase  {
private int x = 1;
private int y = 1;
public void testAddition() {
int z = x + y;
assertEquals(2, z);
}

}


而在 JUnit4 中,测试是由 @Test 注释来识别的,如下所示:

 
 
import  org.junit.Test; import  junit.framework.TestCase; public   class  AdditionTest  { private int x = 1; private int y = 1; @Test public void testAddition() { int z = x + y; assertEquals(2, z); } }

使用注释来识别测试方法的优点是不再需要将所有的方法命名为 testAddition()、testXXX()的形式等等。
例如,下面的方法也可以工作:

 
 
import  org.junit.Test; import  junit.framework.TestCase; public   class  AdditionTest  { private int x = 1; private int y = 1; @Test public void addition() { int z = x + y; assertEquals(2, z); } }

使用这种方法的好处是:
a)允许我们遵循最适合的应用程序的命名约定。
我们可以将测试方法使用与被测试的类相同的名称(由开发组规范约定)。例如,LoginAction.login() 由 LoginActionTest.login()方法测试、LoginAction.check()由LoginActionTest.check()方法测试等等。
b)使用JUnit4后,测试用例类可以不继承TestCase类,所以我们也就可以扩展被测试类了。
这种方法使得测试受保护的方法非常容易,我们只要将测试用例类继承被测试类,就可以测试受保护方法了。 

@Before(SetUp)

JUnit 3 测试运行程序会在运行每个测试之前自动调用 setUp() 方法。该方法一般会初始化字段、准备数据等等。例如下面的 setUp() 方法,用于设定要加载的路由文件:

 

public   void  setUp()  {
// 加载此测试用例的servicerouting配置文件
ServiceRouting.loadConfig("com/demo/servicerouting.conf");
// 
}



在 JUnit4 中,我们仍然可以在每个测试方法运行之前初始化字段或准备数据。然而,完成这些操作的方法不再需要叫做 setUp(),只要用 @Before 注释来指示该方法即可,如下所示:

 

@Before
public   void  initialize()  {
// 加载此测试用例的servicerouting配置文件
ServiceRouting.loadConfig("com/demo/servicerouting.conf");
// 
}



JUnit4允许我们使用 @Before 来注释多个方法,这些方法都在每个测试之前运行:

 

@Before
public   void  initialize()  {
// 加载此测试用例的servicerouting配置文件
ServiceRouting.loadConfig("com/demo/servicerouting.conf");
// 
}

@Before
public   void  prepareRetData()  {
//
}



@After(TearDown)

清除方法与初始化方法类似。在 JUnit3 中,我们要将方法命名为 tearDown() 才可以实现清除方法,但在JUnit4中,只要给方法添加@After标注即可。
例如:

 

    @After
public   static   void  clearContext()  {
ActionContext.getContext().put(StrutsStatics.HTTP_REQUEST, null);
ActionContext.setContext(null);
}



测试方法结束后清除为此测试用例准备的一些数据。
与 @Before 一样,也可以用 @After 来注释多个清除方法,这些方法都在每个测试之后运行。 
最后,我们不再需要显式调用在超类中的初始化和清除方法,只要它们不被覆盖,测试运行程序将根据需要自动为您调用这些方法。
超类中的 @Before 方法在子类中的 @Before 方法之前被调用(这反映了构造函数调用的顺序)。
@After 方法以反方向运行:子类中的方法在超类中的方法之前被调用。否则,多个 @Before 或 @After 方法的相对顺序就得不到保证。


@Before和@After小结

假设测试类中有如下方法定义:

 

@Before
public   void  init() {}
@After
public   void  destroy() {}

则Before、After方法的执行流程如图所示:

浅谈TDD

测试驱动开发,它是敏捷开发的最重要的部分。方法主要是先根据客户的需求编写测试程序,然后再编码使其通过测试。在敏捷开发实施中,开发人员主要从两个方面去理解测试驱动开发。

a)在测试的辅助下,快速实现客户需求的功能。通过编写测试用例,对客户需求的功能进行分解,并进行系统设计。我们发现从使用角度对代码的设计通常更符合后期开发的需求。可测试的要求,对代码的内聚性的提高和复用都非常有益。 
b)在测试的保护下,不断重构代码,提高代码的重用性,从而提高软件产品的质量。可见测试驱动开发实施的好坏确实极大的影响软件产品的质量,贯穿了软件开发的始终。 
在测试驱动开发中,为了保证测试的稳定性,被测代码接口的稳定性是非常重要的。否则,变化的成本就会急剧的上升。所以,自动化测试将会要求您的设计依赖于接口,而不是具体的类。进而推动设计人员重视接口的设计,体现系统的可扩展性和抗变性。 


JUnit4的用法介绍

Java 语言现在支持泛型、枚举、可变长度参数列表和注释,这些特性为可重用的框架设计带来了新的可能。
JUnit4利用 Java 5 的新特性(尤其是注释)的优势,使得单元测试比起用最初的 JUnit 来说更加简单。 

测试方法 @Test

以前所有版本的 JUnit 都使用命名约定和反射来定位测试。例如,下面的代码测试 1 + 1 等于 2:

 

import  junit.framework.TestCase;
public   class  AdditionTest  extends  TestCase  {
private int x = 1;
private int y = 1;
public void testAddition() {
int z = x + y;
assertEquals(2, z);
}

}


而在 JUnit4 中,测试是由 @Test 注释来识别的,如下所示:

 

import  org.junit.Test;
import  junit.framework.TestCase;
public   class  AdditionTest  {
private int x = 1;
private int y = 1;
@Test
public void testAddition() {
int z = x + y;
assertEquals(2, z);
}

}


使用注释来识别测试方法的优点是不再需要将所有的方法命名为 testAddition()、testXXX()的形式等等。
例如,下面的方法也可以工作:

 

import  org.junit.Test;
import  junit.framework.TestCase;
public   class  AdditionTest  {
private int x = 1;
private int y = 1;
@Test
public void addition() {
int z = x + y;
assertEquals(2, z);
}

}


使用这种方法的好处是:
a)允许我们遵循最适合的应用程序的命名约定。
我们可以将测试方法使用与被测试的类相同的名称(由开发组规范约定)。例如,LoginAction.login() 由 LoginActionTest.login()方法测试、LoginAction.check()由LoginActionTest.check()方法测试等等。
b)使用JUnit4后,测试用例类可以不继承TestCase类,所以我们也就可以扩展被测试类了。
这种方法使得测试受保护的方法非常容易,我们只要将测试用例类继承被测试类,就可以测试受保护方法了。 

@Before(SetUp)

JUnit 3 测试运行程序会在运行每个测试之前自动调用 setUp() 方法。该方法一般会初始化字段、准备数据等等。例如下面的 setUp() 方法,用于设定要加载的路由文件:

 

public   void  setUp()  {
// 加载此测试用例的servicerouting配置文件
ServiceRouting.loadConfig("com/demo/servicerouting.conf");
// 
}


在 JUnit4 中,我们仍然可以在每个测试方法运行之前初始化字段或准备数据。然而,完成这些操作的方法不再需要叫做 setUp(),只要用 @Before 注释来指示该方法即可,如下所示:

 

@Before
public   void  initialize()  {
// 加载此测试用例的servicerouting配置文件
ServiceRouting.loadConfig("com/demo/servicerouting.conf");
// 
}


JUnit4允许我们使用 @Before 来注释多个方法,这些方法都在每个测试之前运行:

 

@Before
public   void  initialize()  {
// 加载此测试用例的servicerouting配置文件
ServiceRouting.loadConfig("com/demo/servicerouting.conf");
// 
}

@Before
public   void  prepareRetData()  {
//
}



@After(TearDown)

清除方法与初始化方法类似。在 JUnit3 中,我们要将方法命名为 tearDown() 才可以实现清除方法,但在JUnit4中,只要给方法添加@After标注即可。
例如: 

   @After
public   static   void  clearContext()  {
ActionContext.getContext().put(StrutsStatics.HTTP_REQUEST, null);
ActionContext.setContext(null);
}


测试方法结束后清除为此测试用例准备的一些数据。
与 @Before 一样,也可以用 @After 来注释多个清除方法,这些方法都在每个测试之后运行。 
最后,我们不再需要显式调用在超类中的初始化和清除方法,只要它们不被覆盖,测试运行程序将根据需要自动为您调用这些方法。
超类中的 @Before 方法在子类中的 @Before 方法之前被调用(这反映了构造函数调用的顺序)。
@After 方法以反方向运行:子类中的方法在超类中的方法之前被调用。否则,多个 @Before 或 @After 方法的相对顺序就得不到保证。


@Before和@After小结

假设测试类中有如下方法定义:

 

@Before
public   void  init() {}
@After
public   void  destroy() {}

则Before、After方法的执行流程如图所示:


这种方法有明显的缺陷,如果要初始化的是数据库的链接,或者是一个大的对象的话,而这些资源恰恰是整个测试用例类可以共用的,每次都去申请,确实是种浪费。所以JUnit4引入了@BeforeClass和@AfterClass。


@BeforeClass和@AfterClass

JUnit4 也引入了一个 JUnit3 中没有的新特性:类范围的 setUp() 和 tearDown() 方法。任何用 @BeforeClass 注释的方法都将在该类中的测试方法运行之前刚好运行一次,而任何用 @AfterClass 注释的方法都将在该类中的所有测试都运行之后刚好运行一次。
例如,假设类中的每个测试都使用一个数据库连接、一个非常大的数据结构,或者申请其他一些资源。不要在每个测试之前都重新创建它,您可以创建它一次,用完后将其销毁清除。该方法将使得有些测试案例运行起来快得多。
注意:被注释为 BeforeClass和AfterClass 的方法必须为static方法。 
用法如下:

 
 
    @BeforeClass public   static   void  classInit()  { Map callRet = new HashMap(); List<ErrorCodeMessageBean> list = new ArrayList<ErrorCodeMessageBean>(); list.add(createMsgBean("TDE0001", "第一个错误消息")); list.add(createMsgBean("TDP9999", "格式化{0}{1}")); list.add(createMsgBean("TDE1000~TDF0001", "区间错误消息")); list.add(createMsgBean("TDG0001~", "有下限的区间错误消息")); list.add(createMsgBean("~TDD0001", "有上限的区间错误消息")); list.add(createMsgBean("~", "默认的消息")); callRet.put(ErrorCodeMessageBean.codeMsgBeanKey, list); ServiceCall.expectLastCallReturn(callRet); } @Test public   void  oneTestMethod()  { //. } @AfterClass public   static   void  classDestroy()  { ServiceCall.expectLastCallReturn(null); }

这个特定虽然很好,但是一定要小心对待这个特性。它有可能会违反测试的独立性,并引入非预期的混乱。如果一个测试在某种程度上改变了 @BeforeClass 所初始化的一个对象,那么它有可能会影响其他测试的结果。也就是说,由BeforeClass申请或创建的资源,如果是整个测试用例类共享的,那么尽量不要让其中任何一个测试方法改变那些共享的资源,这样可能对其他测试方法有影响。它有可能在测试套件中引入顺序依赖,并隐藏 bug。

BeforeClass和AfterClass的执行流程如下:

这种方法有明显的缺陷,如果要初始化的是数据库的链接,或者是一个大的对象的话,而这些资源恰恰是整个测试用例类可以共用的,每次都去申请,确实是种浪费。所以JUnit4引入了@BeforeClass和@AfterClass。


@BeforeClass和@AfterClass

JUnit4 也引入了一个 JUnit3 中没有的新特性:类范围的 setUp() 和 tearDown() 方法。任何用 @BeforeClass 注释的方法都将在该类中的测试方法运行之前刚好运行一次,而任何用 @AfterClass 注释的方法都将在该类中的所有测试都运行之后刚好运行一次。
例如,假设类中的每个测试都使用一个数据库连接、一个非常大的数据结构,或者申请其他一些资源。不要在每个测试之前都重新创建它,您可以创建它一次,用完后将其销毁清除。该方法将使得有些测试案例运行起来快得多。
注意:被注释为 BeforeClass和AfterClass 的方法必须为static方法。 
用法如下:

 
 
   @BeforeClass public   static   void  classInit()  { Map callRet = new HashMap(); List<ErrorCodeMessageBean> list = new ArrayList<ErrorCodeMessageBean>(); list.add(createMsgBean("TDE0001", "第一个错误消息")); list.add(createMsgBean("TDP9999", "格式化{0}{1}")); list.add(createMsgBean("TDE1000~TDF0001", "区间错误消息")); list.add(createMsgBean("TDG0001~", "有下限的区间错误消息")); list.add(createMsgBean("~TDD0001", "有上限的区间错误消息")); list.add(createMsgBean("~", "默认的消息")); callRet.put(ErrorCodeMessageBean.codeMsgBeanKey, list); ServiceCall.expectLastCallReturn(callRet); } @Test public   void  oneTestMethod()  { //. } @AfterClass public   static   void  classDestroy()  { ServiceCall.expectLastCallReturn(null); }

这个特定虽然很好,但是一定要小心对待这个特性。它有可能会违反测试的独立性,并引入非预期的混乱。如果一个测试在某种程度上改变了 @BeforeClass 所初始化的一个对象,那么它有可能会影响其他测试的结果。也就是说,由BeforeClass申请或创建的资源,如果是整个测试用例类共享的,那么尽量不要让其中任何一个测试方法改变那些共享的资源,这样可能对其他测试方法有影响。它有可能在测试套件中引入顺序依赖,并隐藏 bug。

BeforeClass和AfterClass的执行流程如下:




测试异常@Test(expected=XXXException.class)

异常测试是 JUnit4 中的最大改进。旧式的异常测试是在抛出异常的代码中放入 try 块,然后在 try 块的末尾加入一个 fail() 语句。
例如,该方法测试被零除抛出一个 ArithmeticException:

 

public   void  testDivisionByZero()  {
try {
int n = 2 / 0;
fail("Divided by zero!");
}

catch (ArithmeticException success) {
assertNotNull(success.getMessage());
}

}


该方法不仅难看,而且写起来也繁琐。在 JUnit 4 中,我们现在可以编写抛出异常的代码,并使用注释来声明该异常是预期的:

 

    @Test(expected  =  BusinessException. class )
public   void  testExecuteNameEmpty()  throws  Exception  {
BookList bListAction = new BookList();
bListAction.setName("");
bListAction.execute();
}


附被测试代码(如果输入name为empty,则抛出BusinessException,若name不为"liming",则抛出MessageException异常):

 
 
    @Override public  String execute()  throws  Exception  { if (StringUtils.isEmpty(name)) { throw new BusinessException("~", "name cant't empty."); } if (!StringUtils.equals("liming", name.trim())) { throw new MessageException(name + " have no limits."); } Map ret = serviceCall.call(JMockService.queryDtlInfo, null); orderId = (String) ret.get("OrderId"); dataList = (List) ret.get("Data"); return SUCCESS; }


参数化测试

为了保证单元测试的严谨性,我们经常要模拟很多种输入参数,来确定我们的功能代码是可以正常工作的,为此我们编写大量的单元测试方法。可是这些测试方法都是大同小异:代码结构都是相同的,不同的仅仅是测试数据和期望输出值。
JUnit4 的参数化测试方法给我们提供了更好的方法,将测试方法中相同的代码结构提取出来,提高代码的重用度,减少复制粘贴代码的痛苦。
例如下面的功能代码(格式化字符串,将驼峰规则的字符串以"_"分隔):

 

public   class  WordDealUtil  {
public static String wordFormat4DB(String name) {
if (name == null{
return null;
}

Pattern p = Pattern.compile("[A-Z]");
Matcher m = p.matcher(name);
StringBuffer sb = new StringBuffer();
while (m.find()) {
if (m.start() != 0) {
m.appendReplacement(sb, ("_" + m.group()).toLowerCase());
}

}

return m.appendTail(sb).toString().toLowerCase();
}

}


没有使用参数化的测试用例代码:

 
 
public   class  WordDealUtilTest  { /** * 测试 null 时的处理情况 */ @Test public void wordFormat4DBNull() { String target = null; String result = WordDealUtil.wordFormat4DB(target); assertNull(result); } /** * 测试空字符串的处理情况 */ @Test public void wordFormat4DBEmpty() { String target = ""; String result = WordDealUtil.wordFormat4DB(target); assertEquals("", result); } /** * 测试当首字母大写时的情况 */ @Test public void wordFormat4DBegin() { String target = "EmployeeInfo"; String result = WordDealUtil.wordFormat4DB(target); assertEquals("employee_info", result); } /** * 测试当尾字母为大写时的情况 */ @Test public void wordFormat4DBEnd() { String target = "employeeInfoA"; String result = WordDealUtil.wordFormat4DB(target); assertEquals("employee_info_a", result); } /** * 测试多个相连字母大写时的情况 */ @Test public void wordFormat4DBTogether() { String target = "employeeAInfo"; String result = WordDealUtil.wordFormat4DB(target); assertEquals("employee_a_info", result); } }

看以上测试用例代码,结构相似,只是输入值与期望输出不同而已,但我们要拷贝很多代码。
使用参数化的测试用例代码:

 
 
@SuppressWarnings( " unchecked " ) @RunWith(Parameterized. class ) public   class  WordDealUtilTestWithParam  { private String expected; private String target; @Parameters public static Collection words() { return Arrays.asList(new Object[][] { { "employee_info", "employeeInfo" },  // 测试一般的处理情况 nullnull },                         // 测试 null 时的处理情况 { "", "" },                             // 测试空字符串时的处理情况 { "employee_info", "EmployeeInfo" },    // 测试当首字母大写时的情况 { "employee_info_a", "employeeInfoA" }// 测试当尾字母为大写时的情况 { "employee_a_info", "employeeAInfo" }  // 测试多个相连字母大写时的情况 }); } /** * 参数化测试必须的构造函数 @param expected     期望的测试结果,对应参数集中的第一个参数 @param target     测试数据,对应参数集中的第二个参数 */ public WordDealUtilTestWithParam(String expected, String target) { this.expected = expected; this.target = target; } /** * 测试将 Java 对象名称到数据库名称的转换 */ @Test public void wordFormat4DB() { Assert.assertEquals(expected, WordDealUtil.wordFormat4DB(target)); } }

很明显,代码简单且很清晰了。在静态方法 words 中,我们使用二维数组来构建测试所需要的参数列表,其中每个数组中的元素的放置顺序并没有什么要求,只要和构造函数中的顺序保持一致就可以了。现在如果再增加一种测试情况,只需要在静态方法 words 中添加相应的数组即可,不再需要复制粘贴出一个新的方法出来了。
这种参数化的测试用例写法,很适用于一些共用的功能方法。



测试异常@Test(expected=XXXException.class)

异常测试是 JUnit4 中的最大改进。旧式的异常测试是在抛出异常的代码中放入 try 块,然后在 try 块的末尾加入一个 fail() 语句。
例如,该方法测试被零除抛出一个 ArithmeticException:

 

public   void  testDivisionByZero()  {
try {
int n = 2 / 0;
fail("Divided by zero!");
}

catch (ArithmeticException success) {
assertNotNull(success.getMessage());
}

}


该方法不仅难看,而且写起来也繁琐。在 JUnit 4 中,我们现在可以编写抛出异常的代码,并使用注释来声明该异常是预期的:

 
 
   @Test(expected  =  BusinessException. class ) public   void  testExecuteNameEmpty()  throws  Exception  { BookList bListAction = new BookList(); bListAction.setName(""); bListAction.execute(); }
附被测试代码(如果输入name为empty,则抛出BusinessException,若name不为"liming",则抛出MessageException异常):
 
 
    @Override public  String execute()  throws  Exception  { if (StringUtils.isEmpty(name)) { throw new BusinessException("~", "name cant't empty."); } if (!StringUtils.equals("liming", name.trim())) { throw new MessageException(name + " have no limits."); } Map ret = serviceCall.call(JMockService.queryDtlInfo, null); orderId = (String) ret.get("OrderId"); dataList = (List) ret.get("Data"); return SUCCESS; }


参数化测试

为了保证单元测试的严谨性,我们经常要模拟很多种输入参数,来确定我们的功能代码是可以正常工作的,为此我们编写大量的单元测试方法。可是这些测试方法都是大同小异:代码结构都是相同的,不同的仅仅是测试数据和期望输出值。
JUnit4 的参数化测试方法给我们提供了更好的方法,将测试方法中相同的代码结构提取出来,提高代码的重用度,减少复制粘贴代码的痛苦。
例如下面的功能代码(格式化字符串,将驼峰规则的字符串以"_"分隔):

 
 
public   class  WordDealUtil  { public static String wordFormat4DB(String name) { if (name == null{ return null; } Pattern p = Pattern.compile("[A-Z]"); Matcher m = p.matcher(name); StringBuffer sb = new StringBuffer(); while (m.find()) { if (m.start() != 0) { m.appendReplacement(sb, ("_" + m.group()).toLowerCase()); } } return m.appendTail(sb).toString().toLowerCase(); } } 没有使用参数化的测试用例代码:  public   class  WordDealUtilTest  { /** * 测试 null 时的处理情况 */ @Test public void wordFormat4DBNull() { String target = null; String result = WordDealUtil.wordFormat4DB(target); assertNull(result); } /** * 测试空字符串的处理情况 */ @Test public void wordFormat4DBEmpty() { String target = ""; String result = WordDealUtil.wordFormat4DB(target); assertEquals("", result); } /** * 测试当首字母大写时的情况 */ @Test public void wordFormat4DBegin() { String target = "EmployeeInfo"; String result = WordDealUtil.wordFormat4DB(target); assertEquals("employee_info", result); } /** * 测试当尾字母为大写时的情况 */ @Test public void wordFormat4DBEnd() { String target = "employeeInfoA"; String result = WordDealUtil.wordFormat4DB(target); assertEquals("employee_info_a", result); } /** * 测试多个相连字母大写时的情况 */ @Test public void wordFormat4DBTogether() { String target = "employeeAInfo"; String result = WordDealUtil.wordFormat4DB(target); assertEquals("employee_a_info", result); } }

看以上测试用例代码,结构相似,只是输入值与期望输出不同而已,但我们要拷贝很多代码。
使用参数化的测试用例代码:

 
 
@SuppressWarnings( " unchecked " ) @RunWith(Parameterized. class ) public   class  WordDealUtilTestWithParam  { private String expected; private String target; @Parameters public static Collection words() { return Arrays.asList(new Object[][] { { "employee_info", "employeeInfo" },  // 测试一般的处理情况 nullnull },                         // 测试 null 时的处理情况 { "", "" },                             // 测试空字符串时的处理情况 { "employee_info", "EmployeeInfo" },    // 测试当首字母大写时的情况 { "employee_info_a", "employeeInfoA" }// 测试当尾字母为大写时的情况 { "employee_a_info", "employeeAInfo" }  // 测试多个相连字母大写时的情况 }); } /** * 参数化测试必须的构造函数 @param expected     期望的测试结果,对应参数集中的第一个参数 @param target     测试数据,对应参数集中的第二个参数 */ public WordDealUtilTestWithParam(String expected, String target) { this.expected = expected; this.target = target; } /** * 测试将 Java 对象名称到数据库名称的转换 */ @Test public void wordFormat4DB() { Assert.assertEquals(expected, WordDealUtil.wordFormat4DB(target)); } }

很明显,代码简单且很清晰了。在静态方法 words 中,我们使用二维数组来构建测试所需要的参数列表,其中每个数组中的元素的放置顺序并没有什么要求,只要和构造函数中的顺序保持一致就可以了。现在如果再增加一种测试情况,只需要在静态方法 words 中添加相应的数组即可,不再需要复制粘贴出一个新的方法出来了。
这种参数化的测试用例写法,很适用于一些共用的功能方法。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
要配置JUnit在IntelliJ IDEA中,可以按照以下步骤进行操作: 1. 首先,确保你已经在IDEA中创建了一个Java项目。 2. 接下来,点击菜单栏的"File",然后选择"Project Structure"。 3. 在弹出的窗口中,选择"Modules"选项卡,并确保你的项目模块被选中。 4. 在右侧的面板中,选择"Dependencies"选项卡,并点击左上角的"+"按钮。 5. 在弹出的菜单中,选择"Library",然后选择"JUnit"。 6. 如果你已经下载了JUnit的jar文件,可以选择"From Maven"选项,然后在搜索框中输入"junit"进行搜索,并选择合适的版本进行导入。 7. 如果你还没有下载JUnit,可以选择"New Library"选项,然后手动下载并导入JUnit的jar文件。 8. 点击"OK"按钮完成配置。 如果你遇到了配置问题,可以参考引用和引用提供的方法进行配置。如果配置不成功,还可以尝试引用提供的最暴力的解决办法,即先写测试代码并使用@Test注解,IDE会报错并提示你导入相关的JUnit环境,你只需要选择刚才下载的JUnit版本进行导入即可。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *3* [用IDEA时的JUnit配置过程](https://blog.csdn.net/tangodope/article/details/125126483)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_1"}}] [.reference_item style="max-width: 50%"] - *2* [详解IDEA JUnit5测试套件运行错误的问题](https://download.csdn.net/download/weixin_38629362/12744182)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_1"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值