单元测试时期望值是抛出异常的情况
非常好的英文怎么写
最近在做TWU关于TDD的作业，对JUnit中测试异常抛出的⽅法进⾏了⼀些学习和思考。
在进⾏单元测试的时候有的时候需要测试某⼀⽅法是否抛出了正确的异常。例如，我有⼀个⽅法，⾥⾯对⼀个List进⾏读取操作，可能会抛出IndexOutOfBoundsException，我希望在单元测试中通过测试保证该⽅法会正确的抛出正确类型的异常。总结起来这样的测试异常是否被正确抛出的⽅法有三种：
指令英文1. try…atch…
@Test
public voidtestExceptionMessage() {hand
try {
new ArrayList<Object>().get(0);
fail("Expected an IndexOutOfBoundsException to be thrown");
} catch (IndexOutOfBoundsException anIndexOutOfBoundsException) {
Message(), is("Index: 0, Size: 0"));
}
}
rob evans这种写法看上去和实现类的写法很相似，当没有异常被抛出的时候fail⽅法会被调⽤，输出测试失败的信息。
2.@Test(expected=xxx)
@Test(expected= IndexOutOfBoundsException.class)
public void empty() {
new ArrayList<Object>().get(0);
}
这种写法看上去简单了⼀些，但是它有⼀个潜在的问题：当被标记的这个测试⽅法中的任何⼀个操作抛出了相应的异常时，这个测试就会通过。这就意味着有可能抛出异常的地⽅并不是我们期望的那个
操作。虽然这种情况可以在写test ca的时候⼈为的避免，但是还是有更好的⽅法来测试异常抛出。
3.ExpectedException Rule
whale怎么读@Rule
public ExpectedException thrown = ();
@Test
public void shouldTestExceptionMessage() throws IndexOutOfBoundsException {
List<Object> list = new ArrayList<Object>();
<(0); // execution will never get past this line
英语幼儿教育}
这种⽅法除了可以指定期望抛出的异常类型之外还可以指定在抛出异常时希望同时给出的异常信息。它需要在测试之前使⽤Rule标记来指定⼀个ExpectedException，并在测试相应操作之前指定期望的Exception类型（如IndexOutOfBoundException.class）
这三种⽅法都可以做到测试相应的操作是否抛出了期望的异常，但是哪种⽅法更好更适合使⽤呢？我的总结是：
@Test(expected=xxx) > 根本不测异常是否正确抛出
ExpectedException > @Test(expected=xxx)
vistatry…fail…catch > ExpectedException
我之所以认为try…fail…catch⽅法⽐ExpectedException好是因为：
1. try…fail…catch更符合⼀般的test function的风格，先进⾏某项操作，在对结果进⾏asrt。⽽ExpectedException的顺序确实先指明期待的结果再进⾏相应的操作。
maroon2. 虽然TDD的最佳实践是每个test function只有⼀个asrt，但是还是在有些情况下会在同⼀个test function⾥使⽤多个asrt来对不同的⽅⾯进⾏测试。但是使⽤ExpectedException进⾏异常测试后，
当前的test function就结束了，如果在expect的相应操作之后还有asrt的话会被⾃动跳过，⽽try…fail…catch则不会跳出当前test function, 其后⾯的asrt依然会被顺序执⾏。
3. ExpectedException是JUnit提供的，因此在使⽤别的测试框架时这样的测试⽅法⽆效。⽽try/catch有更多的测试框架⽀持(fail也是JUnit提供的。使⽤别的测试框架的时候不能使⽤fail来给出测试失败的信息)
practice
