Java 管理不同JUnit测试中的已检查异常

我正在为我的一个方法编写一个Java单元测试。方法声明如下所示：

public int convertToInteger() throws InvalidRomanNumberException
{
    int result=0;
    BaseRomanNumeral num1, num2; 
    int i=0;
    if(!validOperation())
        throw new InvalidRomanNumberException();
}

现在我正在尝试编写两个单元测试。一个是测试是否抛出了正确的异常。另一个是确保写入转换发生。这就是我的测试用例的外观

@Test
public void testRomanNumberConversion() {
    String romanValue="MCMII";
    RomanNumber num=new RomanNumber(romanValue);
    assertEquals(1903,num.convertToInteger());  
}

@Test(expected = InvalidRomanNumberException.class)
public void testInvalidRomanNumberExceptionThrown()  {
    String romanValue="MCMIIII";
    RomanNumber num=new RomanNumber(romanValue);
    num.convertToInteger(); 
}

---

对于这两个测试用例，我得到一个错误，称为unhandledInvalidRomanNumberException。只有在向每个方法定义添加InvalidRomanNumberException时，才会解决此问题。但我认为这不是正确的方法。我想和你们其他人核实一下，这里的标准是什么？如何解析此未处理的异常消息

由于它看起来像是一个已检查的异常InvalidRomanNumberException，因此您必须用一个

try catch

包围它，或者声明该方法

抛出InvalidRomanNumberException

<代码>JUnit与否，这是标准

也就是说，您所期望的测试用例方法将抛出一个

InvalidRomanNumberException

，理想情况下应该声明它抛出一个

，因为用
try catch
来抑制它是没有意义的，因为您的测试用例将失败。另一方面，您期望不会引发异常的测试用例方法可以在
convertToInteger
方法周围使用
try-catch
，并且无论是否引发异常，该测试用例都应该对
convertToInteger
方法的预期结果使用
assert

JUnit测试用例的最终结果应该是测试是否通过。运行时的异常将表明两者都不存在。JUnit测试用例不能崩溃
 这感觉更像是一个未检查的异常，而不是一个已检查的异常

回想一下两者之间的区别：选中的异常意味着可以合理地从中恢复，例如丢失的文件或错误的URL。未经检查/运行时异常意味着无法恢复，例如除以零

如果用户输入了无效的罗马数字，那么说他们可以恢复并重试可能没有意义——转换层不应该对此负责。这听起来更像是一件应该在实例化时决定的事情

如果您改为使自定义异常扩展
RuntimeException
，那么您就不需要声明要抛出它（如果这样做了，它就不会有任何效果），您也不必在测试中处理它

另一种方法是声明它将被抛出到您的测试中。这样做的好处是允许您保持这些异常处于检查状态，并确保测试不会抱怨您没有处理潜在的异常，从而导致未捕获或未捕获

@Test
public void testRomanNumberConversion() throws InvalidRomanNumberException {
    String romanValue = "MCMII";
    RomanNumber num = new RomanNumber(romanValue);
    assertEquals(1903, num.convertToInteger());  
}

@Test(expected = InvalidRomanNumberException.class)
public void testInvalidRomanNumberExceptionThrown() throws InvalidRomanNumberException {
    String romanValue = "MCMIIII";
    RomanNumber num = new RomanNumber(romanValue);
    num.convertToInteger(); 
}

所以你的建议是，我只需添加一个IDRomanNumber例外。如果出现异常，测试就会失败。因此，对于这个抛出exception@bob_d：否。我的建议是，不期望出现异常的方法应该使用
try catch
，而期望出现异常的方法应该使用
throws
。在前一种情况下，不管是否引发异常，都应该断言从
convertToInteger
方法中所期望的结果。在后面的示例中，您断言异常是预期的
。请看我对第二段最后几行的编辑。请投票人留下评论好吗？不确定为什么一个被接受的答案会导致一个下降的声音没有理由添加一个
尝试
catch
在
testromanumberconversion（）中阻塞。最简单的想法就是添加
抛出InvalidRomanNumberException
。如果测试用例永远不会引发异常，那么添加
抛出InvalidRomanNumberException
不会造成任何伤害。如果测试抛出该异常（或任何异常），测试将失败，因为JUnit本身将捕获该异常并报告测试失败（提供有用的失败堆栈跟踪！）。测试应该尽可能简单（但不简单）。所以你否决了这个，因为你不同意我的意见？你认为留下评论而不是投否决票会是更好的选择吗？请阅读以下内容：。我的答案是草率的、明显的还是危险的错误？我不完全同意为所有测试用例方法声明
throws
的建议。不需要异常的测试不应该因为异常而在运行时导致编程异常。JUnit测试用例不应该崩溃。它应该断言
convertToInteger
方法的最终结果，并抑制任何异常。这种测试用例的最终结果应该是测试是否通过。运行时出现异常将表明两者都不存在。嘿，感谢您的详细解释。它确实帮助我理解检查和未检查的异常better@ChetanKinger当前位置我不一定不同意你的观点，因此我建议首先将其更改为未经检查的例外。我的信念是，实际上可以恢复的异常确实需要检查，但在这种情况下，我觉得这种声明很好。引发上述异常的唯一方法是，如果输入了无效的罗马数字，并且至少在第一个测试用例中不会发生。