Как издеваться над строкой с помощью mockito?

Проблема в том, что класс String в Java отмечен как final, поэтому вы не можете имитировать использование традиционных фреймворков для имитации. Согласно часто задаваемым вопросам по Mockito, это также ограничение этой структуры.

Как насчет того, чтобы просто создать String с неправильным именем кодировки? Видеть

public String(byte bytes[], int offset, int length, String charsetName)

Издевательство над String почти наверняка плохая идея.

Если все, что вы собираетесь делать в своем блоке catch, - это генерировать исключение во время выполнения, вы можете сэкономить время на вводе текста, просто используя объект Charset для указания имени вашего набора символов.

public final class A{
    public static String f(String str){
        return new String(str.getBytes(Charset.forName("UTF-8")));
    }
}

Таким образом, вы не поймаете исключение, которое никогда не произойдет только потому, что компилятор говорит вам об этом.

Как указывали другие, вы не можете использовать Mockito для издевательства над последним классом. Однако более важным моментом является то, что тест не особенно полезен, потому что он просто демонстрирует, что String.getBytes() может вызвать исключение, что он, очевидно, может сделать. Если вы серьезно относитесь к тестированию этой функции, я думаю, вы могли бы добавить параметр для кодировки в f() и отправить неверное значение в тест.

Кроме того, вы вызываете ту же проблему для вызывающего A.f(), потому что A является окончательным, а f() - статическим.

Эта статья может быть полезна, чтобы убедить ваших коллег быть менее догматичными относительно 100% покрытия кода: Как потерпеть неудачу при 100% тестовом покрытии.

Из своей документации JDave не может удалить модификаторы final из классов, загруженных загрузчиком классов начальной загрузки. Сюда входят все классы JRE (из java.lang, java.util и т. Д.).

Инструмент, который позволяет имитировать что угодно, - это JMockit.

С JMockit ваш тест может быть записан как:

import java.io.*;
import org.junit.*;
import mockit.*;

public final class ATest
{
   @Test(expected = UnsupportedOperationException.class)
   public void test() throws Exception
   {
      new Expectations()
      {
         @Mocked("getBytes")
         String aString;

         {
            aString.getBytes(anyString);
            result = new UnsupportedEncodingException("Parsing error.");
         }
      };

      A.f("test");
   }
}

при условии, что полный класс «А»:

import java.io.*;

public final class A
{
   public static String f(String str)
   {
      try {
         return new String(str.getBytes("UTF-8"));
      }
      catch (UnsupportedEncodingException e) {
         throw new UnsupportedOperationException(e);
      }
   }
}

Я действительно выполнил этот тест на своей машине. (Обратите внимание, что исходное проверенное исключение я заключил в исключение времени выполнения.)

Я использовал частичное издевательство через @Mocked("getBytes"), чтобы JMockit не издевался над всем в классе java.lang.String (только представьте, к чему это может привести).

В этом тесте действительно нет необходимости, потому что «UTF-8» - это стандартная кодировка, которая должна поддерживаться во всех JRE. Следовательно, в производственной среде блок catch никогда не будет выполнен.

Однако «потребность» или желание прикрыть блокировку улова все еще в силе. Итак, как избавиться от теста, не уменьшая процент покрытия? Вот моя идея: вставить строку с assert false; в качестве первого оператора внутри блока catch и заставить инструмент Code Coverage игнорировать весь блок catch при сообщении о мерах покрытия. Это один из моих «TODO-пунктов» для JMockit Coverage. 8 ^)

Мокито не может издеваться над выпускными классами. JMock в сочетании с библиотекой от JDave может. Вот инструкции.

JMock не делает ничего особенного для финальных классов, кроме как полагаться на библиотеку JDave для завершения всего в JVM, поэтому вы можете поэкспериментировать с использованием нефинализатора JDave и посмотреть, будет ли Mockito затем издеваться над ним.

Вы также можете использовать расширение PowerMock Mockito для имитации конечных классов / методов даже в системных классах, таких как String. Однако я бы также посоветовал не имитировать getBytes в этом случае и попытаться настроить ваше ожидание так, чтобы вместо этого использовалась настоящая String, заполненная ожидаемыми данными.

Вы будете тестировать код, который никогда не может быть выполнен. Поддержка UTF-8 требуется на каждой виртуальной машине Java, см. http://java.sun.com/javase/6/docs/api/java/nio/charset/Charset.html

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

Что это за цель охвата? Некоторые скажут, что съемка для 100% покрытия не всегда хорошая идея.

Кроме того, это не способ проверить, была ли задействована блокировка catch. Правильный способ - написать метод, который вызывает возникновение исключения, и сделать наблюдение за выбросом исключения критерием успеха. Вы делаете это с помощью аннотации JUnit @Test, добавляя «ожидаемое» значение:

@Test(expected=IndexOutOfBoundsException.class) public void outOfBounds() {
   new ArrayList<Object>().get(1);
}

Вы пробовали передать недопустимое имя charsetName в getBytes (String)?

Вы можете реализовать вспомогательный метод для получения charsetName и переопределить этот метод в своем тесте на бессмысленное значение.

Возможно, вместо A.f (String) следует использовать A.f (CharSequence). Вы можете издеваться над CharSequence.

Если вы можете использовать JMockit, посмотрите ответ Роджерио.

Если и только если ваша цель - получить покрытие кода, но не фактически имитировать то, как отсутствующий UTF-8 будет выглядеть во время выполнения, вы можете сделать следующее (и что вы не можете или не хотите использовать JMockit):

public static String f(String str){
    return f(str, "UTF-8");
}

// package private for example
static String f(String str, String charsetName){
    try {
        return new String(str.getBytes(charsetName));
    } catch (UnsupportedEncodingException e) {
        throw new IllegalArgumentException("Unsupported encoding: " + charsetName, e);
    }
}

public class TestA {

    @Test(expected=IllegalArgumentException.class)
    public void testInvalid(){
        A.f(str, "This is not the encoding you are looking for!");
    }

    @Test
    public void testNormal(){
        // TODO do the normal tests with the method taking only 1 parameter
    }
}

Вы можете изменить свой метод, чтобы использовать интерфейс CharSequence:

public final class A {
    public static String f(CharSequence str){
        try {
            return new String(str.getBytes("UTF-8"));
        } catch (UnsupportedEncodingException e) {
            // This is the catch block that I want to exercise.
            ...
        }
    }
}

Таким образом, вы все еще можете передать String, но вы можете издеваться как хотите.

вместо насмешливой строки введите строковое значение в методе настройки, как показано ниже

public void setup() throws IllegalAccessException {
    FieldUtils.writeField(yourTestClass, "stringVariableName", "value", true);
}

Если у вас есть блок кода, который никогда не может быть запущен, и требование руководства о 100% тестовом покрытии, то что-то нужно изменить.

Что вы можете сделать, так это сделать кодировку символов переменной-членом и добавить в свой класс частный конструктор пакета, который позволяет вам передать его. В модульном тесте вы можете вызвать новый конструктор с бессмысленным значением для кодировки символов .