我已经为以下函数编写了Junit测试用例。当检查JACOCO测试覆盖率时。它显示测试用例只覆盖了try块。我是编写测试用例的新手。如何在测试用例中覆盖异常和catch块
这里有一个方法
public static List<Student> readCsvFile(String fileName)
{
BufferedReader fileReader = null;
//logic to read file
}
catch (Exception e)
{
System.out.println("Error in CsvFileReader !!!");
e.printStackTrace();
} finally
{
try
{
fileReader.close();
} catch (IOException e)
{
System.out.println("Error while closing fileReader !!!");
e.printStackTrace();
}
}
return students;
}
和测试方法
@Test
public void ReadCsvFileTest()
{
String fileName = "test.csv";
List<Student> result = new ArrayList<Student>();
result = CsvFileReader.readCsvFile(fileName);
Student student1 = null;
Iterator<Student> it = result.iterator();
while (it.hasNext())
{
Student s = it.next();
if ("471908US".equals(s.getId()))
{
student1 = s;
break;
}
}
assertTrue(student1 != null);
}
考虑到被测试方法的当前特征,实现完全覆盖并不容易:只有在try块中抛出异常时,才会执行catch块。
解决这个问题的一种方法是:不要传入文件名,而是传入读卡器对象本身。比如:
public static List<Student> readCsvFile(String fileName) {
return readCsvFile(new BufferedReader(fileName));
}
static List<Student> readCsvFile(BufferedReader reader) {
try {
...
} catch( ...
现在您可以为第二种方法编写几个特定的单元测试。您保留简单地进行“正确”读取的测试;但是您在传入模拟阅读器对象的地方添加一个......这只是在某个时候抛出一个异常。请注意,我将新方法设置为受包保护——您可能不想使用那个“公共”;将其设为私有会阻止它进行单元测试。
这应该有助于您实现全面覆盖。当然,您还需要至少一个测试来“覆盖”字符串获取方法。
注意:
在这种情况下,您可能会经常考虑在类中引入其他依赖项。下面是一个粗略的例子。为读者创建一个工厂:
interface BufferedReaderFactory
{
public BufferedReader createBufferedReader(String fileName) throws IOException;
}
然后,您将有一个几乎不需要任何测试的简单实现,例如类似的东西:
class BufferedReaderFactoryImpl implements BufferedReaderFactory
{
@Override
public BufferedReader createBufferedReader(String fileName) throws IOException
{
return new BufferedReader(new FileReader(fileName));
}
}
然后你必须找到一种方法,将这种依赖注入到你的类中。我通常在日常工作中使用Guice,但您可以尝试一些简单的方法,比如使用构造函数注入,并使您的方法非静态。下面是一个例子:
class CsvFileReader
{
private final BufferedReaderFactory factory;
public CsvFileReader(BufferedReaderFactory factory)
{
this.factory = factory;
}
public List<Student> readCsvFile(String fileName)
{
BufferedReader fileReader = null;
try
{
fileReader = factory.createBufferedReader(fileName);
...
}
catch(IOException e)
{
...
}
finally
{
...
}
return new LinkedList<>();
}
}
使用像Mockito这样的模拟框架,这个类在IOException
-s的情况下的行为现在更容易测试(请注意,您也可以返回从工厂引发异常的模拟)。这是一个示例:
@RunWith(MockitoJUnitRunner.class)
public class MyTest
{
@Mock
private BufferedReaderFactory mockFactroy;
@Test
public void testIOException() throws IOException
{
String ivalidFileName = "invalid.txt";
//throw exception in case that invalid file name is passed to the factory
Mockito.when(mockFactroy.createBufferedReader(ivalidFileName)).thenThrow(new IOException("Hello!"));
CsvFileReader csvFileReader = new CsvFileReader(mockFactroy);
//invoke with a factory that throws exceptions
csvFileReader.readCsvFile(ivalidFileName);
//...
//and make a sensible test here, e.g. check that empty list is returned, or proper message is logged, etc.
}
}
当然,您可以在没有Mockito的情况下实现这一点——通过实现一个测试工厂。但这更麻烦,尤其是在更复杂的用例中。一旦抛出IOException
,您将获得JaCoCo提供的相应覆盖率报告。
还要注意这里提到的JaCoCo的一个局限性,在第节中,除了例外,源代码行没有覆盖范围。为什么?
我试图创建一个测试来验证我的代码(见下面的伪代码)是否正确捕获异常。我知道JUnit能够测试代码是否用以下代码抛出异常: 然而,我正在测试的软件的原始代码捕获了这个异常并打印了一条消息 JUnit是否有办法验证此消息?或者我应该改变一下我的流行语? 注:我已阅读,我应使用以下内容: 但是程序崩溃,因为它无法识别对象。 我尝试测试的方法的伪代码(出于隐私原因,不要发布确切的内容):
我正在尝试为这样的情况编写测试用例,在这个情况下,我期待的是datatruncation异常,我试图使用assert equals和比较消息来断言相同的情况,但是看起来像是比较两个字符串,有没有更好的方法来为这样的异常编写测试用例。 我正在使用JUnit5
在junit5和Mockito中如何覆盖返回void的方法的catch块。 下面提到的dump方法返回void并抛出RepositoryException和JSONException。 TidyJosnitemWrite.dump(节点,stringWriter,-1);
问题内容: 我想介绍getKeyStore()方法,但是我不知道如何介绍NoSuchAlgorithmException,KeyStoreException,UnrecoverableKeyException和CertificateException的catch块。我的方法是: 我该怎么做? 问题答案: 您可以 模拟 该块的任何句子以引发要捕获的异常。 示例模拟对throw 的调用。在这种情况下,
问题内容: 我真的是java的新手。 我正在构造函数上运行一些JUnit测试。构造函数是这样的:如果为其参数之一赋予null或空字符串,则应该抛出异常。 当我在JUnit中使用null或空字符串参数测试此构造函数时,即使我几乎100%确信将此类参数传递给它时,构造函数方法确实会引发异常,我也会看到一条红色的条。 如果该方法以预期的方式引发异常,则JUnit中是否应该没有绿色的条形?还是当异常抛出按
问题内容: 编辑:目前没有JUnit 4。 嗨,您好, 我对使用JUnit进行“智能”异常测试有疑问。目前,我这样做是这样的: 如您所见,对于每个应该引发异常的函数,我都需要一个try / catch块。似乎不是执行此操作的好方法-还是没有可能减少try / catch的使用? 问题答案: 我建议您需要分解为多个单独的测试。各个try / catch块似乎彼此非常独立。您可能还希望将通用初始化逻辑