Schreiben Junit-test zu decken, Ausnahme-und catch-block

Habe ich geschrieben Junit-Testfall für folgende Funktion. Wenn die Option aktiviert ist JACOCO Testabdeckung. Es zeigt nur try-block ist bedeckt von test-Fall. Ich bin Neuling auf dem schreiben von Testfällen. Wie die exceptions und catch-block kann abgedeckt werden, die in Testfällen

Hier ist eine Methode

  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;
    }

Und TestMethod

@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);
    }
  • Du bekommst nur die Abdeckung für die exception-block wird eine Ausnahme geworfen.
  • CsvFileReader.readCsvFile("notexisting.csv") sollten Sie die fangen
  • Als Kompass empfehlen Sie eine Ausnahme innerhalb des try-Blocks während der Testausführung. Normalerweise würde ich die Verwendung eines mocking-Frameworks wie Mockito um dies zu erreichen. Aber vielleicht ist in Ihrem Fall reicht es aus, übergeben Sie einen ungültigen Dateinamen.
InformationsquelleAutor ronypatil | 2016-12-12
  1. 3

    In solchen Situationen kann man oft betrachten die Einführung von zusätzlichen Abhängigkeiten zu Ihrer Klasse. Hier ist, was ich meine, mit einem groben Beispiel. Erstellen Sie eine Fabrik für die Leser:

    interface BufferedReaderFactory
{
    public BufferedReader createBufferedReader(String fileName) throws IOException;
}

    Dann haben Sie eine triviale Implementierung, Bedarf kaum testen, z.B. etwas ähnliches:

    class BufferedReaderFactoryImpl implements BufferedReaderFactory
{
    @Override
    public BufferedReader createBufferedReader(String fileName) throws IOException
    {
        return new BufferedReader(new FileReader(fileName));
    }
}

    Dann müssen Sie einen Weg finden, um zu injizieren, diese Abhängigkeit in Ihrer Klasse. Normalerweise verwende ich Guice in meiner täglichen Arbeit, aber Sie können versuchen, etwas so einfaches wie über constructor injection und machen Ihre Methode nicht statisch. Hier ist ein Beispiel:

    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<>();
    }
}

    Mit einem mocking-framework wie Mockito das Verhalten dieser Klasse im Fall von IOException-s ist einfacher zu testen jetzt (beachten Sie, dass Sie möglicherweise auch zurück, mocks, die Ausnahmen aus der Fabrik). Hier ist ein Beispiel:

    @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.
    }
}

    Können Sie dies tun, ohne Mockito, natürlich - durch die Implementierung einer test factory. Aber das ist eher umständlich, vor allem in komplizierteren Fällen verwenden. Sobald die IOException geworfen wird, erhalten Sie entsprechende Berichterstattung Bericht von JaCoCo.

    Auch mind eine Einschränkung des JaCoCo erwähnt hier, in Abschnitt Source-code-Zeilen mit Ausnahmen zeigen, keine Abdeckung. Warum?

    InformationsquelleAutor Lachezar Balev
  2. 2

    Angesichts der aktuellen Signatur der Methode in der Erprobung, erste volle Deckung ist nicht leicht: Ihre catch-block wird nur ausgeführt, wenn eine Ausnahme geworfen wird, in Ihrem try-block.

    Einen Weg, um dieses Problem zu lösen: nicht-pass in den Namen der Datei, sondern das reader-Objekt selbst. Wie: 

    public static List<Student> readCsvFile(String fileName) {
  return readCsvFile(new BufferedReader(fileName));
}

static List<Student> readCsvFile(BufferedReader reader) { 
  try {
    ...
  } catch( ...

    Nun können Sie schreiben mehrere bestimmte unit-tests für die zweite Methode. Halten Sie Ihre tests, die einfach das tun, "richtig" zu Lesen; aber Sie fügen ein, wo Sie übergeben eine verspottet reader-Objekt ... dass Sie einfach eine Exception wirft irgendwann. Bitte beachten Sie, dass ich machte, dass die neue Methode nur package - protected- Sie wollen wahrscheinlich nicht zu verwenden, dass "öffentlich" und privat würde verhindern, dass es als Einheit getestet.

    Die Ihnen helfen sollen eine vollständige Abdeckung. Natürlich müssen Sie auch mindestens einen test, um die "Deckung" der string-Methode nehmend, zu.

    Einige Hinweise:

    1. Vorsichtig sein, über die das Rad neu erfinden möchte. Es gibt viele vorhandene CSV-Parser bereits. Und seien Sie versichert: das schreiben einer richtige CSV-parser, der in der Lage ist, sich mit "richtigen" input CSV ist viel härter, als es klingt. Wenn dies nicht für "Lernzwecke" ich rate dringend zu nicht schreiben Sie Ihre eigenen CSV-parser.
    2. Vorsichtig sein, über solche Dinge statische. Wie gesagt, eine echte CSV-parser ist eine komplizierte Sache und lohnt sich seine komplett eigene Klasse. Also keine statische Hilfsmethoden - eine normale Klasse, die Sie instanziieren, um Sie dann rufen Sie die Methoden auf (das würde auch für die Verwendung dependency injection, die helfen würde, mit dem problem, das Sie zu Fragen, ... immer Ausnahmen in try-Blöcke)
    3. Sie fangen Ausnahme in deinem code-Beispiel. Tun Sie das nicht - versuchen Sie, fangen genau diese Ausnahmen, dass der code tatsächlich produzieren (wahrscheinlich IOException in Ihrem Fall).
    InformationsquelleAutor GhostCat
Schreibe einen Kommentar