Тестирование пустот методом JUNIT

У меня есть класс java, полный методов void, и я хочу сделать несколько unit test, чтобы получить максимальный охват кода.

Например, у меня есть этот метод:

protected static void checkifValidElements(int arg1,  int arg2) {
    method1(arg1);
    method2(arg1);
    method3(arg1, arg2);
    method4(arg1, arg2);
    method5(arg1);
    method6(arg2);
    method7();
}

Его плохо назвали по причине, потому что я перевел код для лучшего понимания. Каждый метод проверяет, являются ли аргументы каким-то образом и хорошо написаны.

Пример:

private static void method1(arg1) {
    if (arg1.indexOf("$") == -1) {

        //Add an error message 
        ErrorFile.errorMessages.add("There is a dollar sign in the specified parameter");
    }
}

My unit test отлично маскирует мелкие методы, потому что я прошу их проверить, содержит ли ErrorFile сообщение об ошибке, но я не вижу, как я могу проверить свой метод checkIfValidElements, он ничего не возвращает или ничего не изменяет. Когда я запускаю покрытие кода с помощью Maven, он сообщает мне, что unit test doesent охватывает эту часть моего класса.

Единственное, что я вижу, это изменить этот метод, чтобы вернуть значение int или bollean, например:

protected static int checkifValidElements(int arg1,  int arg2) {
    method1(arg1);
    method2(arg1);
    method3(arg1, arg2);
    method4(arg1, arg2);
    method5(arg1);
    method6(arg2);
    method7();
    return 0;
}

С помощью этого метода я могу сделать утверждение равным, но мне кажется, что это бесполезно. Проблема в том, что у меня есть пара классов, которые разработаны таким образом и уменьшают покрытие unit test%.

Ответ 1

Я хочу сделать несколько unit test, чтобы получить максимальный охват кода

Покрытие кода никогда не должно быть целью написания модульных тестов. Вы должны написать модульные тесты, чтобы доказать, что ваш код верен, или помочь вам лучше его разработать, или помочь кому-то понять, что должен делать код.

но я не вижу, как я могу проверить свой метод checkIfValidElements, он ничего не возвращает или ничего не меняет.

Ну, вы должны, вероятно, дать несколько тестов, которые между ними проверяют, что все 7 методов называются надлежащим образом - как с недопустимым аргументом, так и с допустимым аргументом, каждый раз проверяя результаты ErrorFile.

Например, предположим, что кто-то удалил вызов:

method4(arg1, arg2);

... или случайно изменил порядок аргументов:

method4(arg2, arg1);

Как бы вы заметили эти проблемы? Идите от этого и спроектируйте тесты, чтобы доказать это.

Ответ 2

Если ваш метод не имеет побочных эффектов и ничего не возвращает, значит, он ничего не делает.

Если ваш метод выполняет некоторые вычисления и возвращает результат этого вычисления, вы можете, очевидно, достаточно утверждать, что возвращаемый результат верен.

Если ваш код ничего не возвращает, но имеет побочные эффекты, вы можете вызвать код, а затем утверждать, что произошли правильные побочные эффекты. Какие побочные эффекты будут определять, как вы выполняете проверки.

В вашем примере вы вызываете статические методы из своих невозвратных функций, что делает его сложным, если вы не можете проверить, что результат всех этих статических методов правильный. Лучший способ - с точки зрения тестирования - вводить фактические объекты в том, что вы вызываете методы. Затем вы можете использовать что-то вроде EasyMock или Mockito для создания Mock Object в вашем unit test и вводить макет объекта в класс. Затем Mock Object позволяет утверждать, что были вызваны правильные функции с правильными значениями и в правильном порядке.

Например:

private ErrorFile errorFile;

public void setErrorFile(ErrorFile errorFile) {
    this.errorFile = errorFile;
}

private void method1(arg1) {
    if (arg1.indexOf("$") == -1) {

        //Add an error message 
        errorFile.addErrorMessage("There is a dollar sign in the specified parameter");
    }
}

Затем в вашем тесте вы можете написать:

public void testMethod1() {
    ErrorFile errorFile = EasyMock.createMock(ErrorFile.class);
    errorFile.addErrorMessage("There is a dollar sign in the specified parameter");
    EasyMock.expectLastCall(errorFile);
    EasyMock.replay(errorFile);

    ClassToTest classToTest = new ClassToTest();
    classToTest.setErrorFile(errorFile);
    classToTest.method1("a$b");

    EasyMock.verify(errorFile); // This will fail the test if the required addErrorMessage call didn't happen
}

Ответ 3

Вы можете unit test использовать метод void, утверждая, что он имеет соответствующий побочный эффект. В примере method1 ваш unit test может выглядеть примерно так:

public void checkIfValidElementsWithDollarSign() {
    checkIfValidElement("$",19);
    assert ErrorFile.errorMessages.contains("There is a dollar sign in the specified parameter");
}

Ответ 4

Я думаю, вам следует избегать написания метода побочных эффектов. Возвращайте true или false из вашего метода, и вы можете проверить эти методы в модульных тестах.

Ответ 5

Если ваш метод недействителен и вы хотите проверить исключение, вы можете использовать expected: https://weblogs.java.net/blog/johnsmart/archive/2009/09/27/testing-exceptions-junit-47

Ответ 6

Вы можете узнать что-то, называемое "насмешкой". Вы можете использовать это, например, для проверки: - была вызвана функция - функция называлась x раз - функция была вызвана как минимум x раз - вызывается функция с определенным набором параметров. В вашем случае, например, вы можете использовать насмешку, чтобы проверить, что метод3 был вызван один раз с тем, что вы передаете как arg1 и arg2.

Посмотрите на них: https://code.google.com/p/mockito/ https://code.google.com/p/powermock/