Почему file.bufferedReader()
дает мне NullPointerException
здесь?
val file = mock<File>()
when(file.bufferedReader()).thenThrow(IOException::class.java)
Почему file.bufferedReader()
дает мне NullPointerException
здесь?
val file = mock<File>()
when(file.bufferedReader()).thenThrow(IOException::class.java)
В соответствии с этой веткой Невозможно смоделировать класс BufferedWriter в junit
Вы можете имитировать классы ввода-вывода Java (включая их конструкторы, поэтому будущие экземпляры также будут имитироваться) с помощью библиотеки JMockit, хотя вы, вероятно, столкнетесь с трудностями, такими как исключение NullPointerException из конструктора Writer() (в зависимости от того, как была выполнена имитация и какой Издевались над классами IO).
Однако обратите внимание, что Java IO API содержит множество взаимодействующих классов и глубокую иерархию наследования. В вашем примере класс FileWriter, вероятно, также необходимо будет смоделировать, иначе будет создан фактический файл.
Кроме того, использование классов ввода-вывода в коде приложения обычно является просто деталью реализации, которую можно легко изменить. Например, вы можете переключиться с потоков ввода-вывода на писатели, с обычного ввода-вывода на NIO или использовать новые утилиты Java 8. Или используйте стороннюю библиотеку ввода-вывода.
Суть в том, что пытаться имитировать классы ввода-вывода — это просто ужасно плохая идея. Еще хуже, если (как предлагается в другом ответе) вы измените клиентский код, чтобы в SUT были введены писатели и т. Д. Внедрение зависимостей просто не для такого рода вещей.
Вместо этого используйте настоящие файлы в локальной файловой системе, желательно из тестового каталога, который можно удалить после теста, и/или используйте фиксированные файлы ресурсов только для чтения. Локальные файлы работают быстро и надежно, а также позволяют проводить более полезные тесты. Некоторые разработчики скажут, что «тест не является модульным тестом, если он затрагивает файловую систему», но это просто догматический совет.