Почему я не должен насмехаться Файл или путь

Question

Я борется с пониманием минного поля, которое является классами, поддерживаемыми API-интерфейсом jmockit Mocking. Я нашел то, что, как я думал, было ошибкой с файлом, но проблема была просто закрыта, сказав: «Не издевайтесь над файлом или путём», в котором нет объяснений. Может ли кто-то здесь помочь мне понять, почему некоторые классы не должны насмехаться и как я должен работать над этим. Я пытаюсь внести вклад в библиотеку с отчетами об ошибках, но каждый из файлов, которые я делаю, оставляет меня еще более запутанным. Простите мое невежество, но если кто-нибудь может указать мне на обоснование запретных макетов и т. Д., Я бы очень признателен.

Answer 1

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

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

Но при этом я сделаю попытку.

Единичные тесты должны проводиться с проверкой отдельных классов, а не взаимодействий между классами. Они называются интеграционными тестами.

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

Одним исключением из этого правила, на мой взгляд, являются объекты доступа к данным. Нет смысла тестировать один из них без подключения к удаленной базе данных. Ваш тест должен подтвердить правильность работы вашего кода. Это требует подключения к базе данных в случае объектов доступа к данным. Они должны быть записаны как транзакционные: засеять базу данных, выполнить тест и отменить действия теста. Когда вы закончите, база данных должна быть в том же состоянии.

Как только ваши объекты доступа к данным сертифицированы как работающие правильно, все клиенты, которые их используют, должны издеваться над ними. Не нужно повторять проверку.

Вы не должны издеваться над классами в JVM.

Вы спрашивали, почему в отношении файла или потока в частности - вот что. Возьмите его или проигнорируйте.

Вам не нужно тестировать классы JVM, потому что Sun/Oracle уже это сделали. Вы знаете, что они работают. Вы хотите, чтобы ваш класс использовал эти классы, потому что неудачный тест выявит тот факт, что необходимый файл недоступен. Макет не скажет мне, что я пренебрег тем, что поместил требуемый файл в свой CLASSPATH. Я хочу узнать во время тестирования, а не в производстве.

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

Answer 2

В модульном тесте вы должны проверить, что ваш код поступает правильно. Вы можете издеваться над любыми внешними фрагментами кода, которые не являются проверенным прямым кодом. Это строгое определение модульного теста, и предполагается, что существует еще одна форма тестирования, называемая интеграционным тестированием, которая будет выполнена позже. При тестировании интеграции вы проверяете, как ваш код взаимодействует с внешними элементами, такими как БД или другой веб-сервис, или сеть, или жесткий диск.

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

Например:

public void processFile(File f) { 
    if (f.exists()) { 
     //perform some tasks 
    } else { 
     //perform some other tasks 
    } 
} 

Чтобы правильно блок-тестирования кода выше, я бы работать по крайней мере два модульных тестов. Один проверить, существует ли файл, а другой проверить, что мой код делает правильную вещь, когда файл не существует. Поскольку модульное тестирование, IMHO, только тестирует мой код и не выполняет интеграционные тесты, тогда отлично справиться с файлом File, чтобы вы могли протестировать обе ветви этого метода.

Во время тестирования интеграции вы можете протестировать реальный файл, так как ваше приложение будет взаимодействовать с его окружением.

Попробуйте Mockito:

Я не знаю, почему JMockit не позволяет издеваться класса File. В Мокито это можно сделать. Пример ниже.

import java.io.File; 
import static org.mockito.Mockito.mock; 
import static org.mockito.Mockito.when; 

public class NewMain {  

    public static void main(String[] args) { 
     File f = mock(File.class); 
     when(f.exists()).thenReturn(true); 
     System.out.println("f.exists = " + f.exists()); 
    } 

}