mocking file.bufferedReader() дава NullPointerException

Защо file.bufferedReader() ми дава NullPointerException тук?

val file = mock<File>()
when(file.bufferedReader()).thenThrow(IOException::class.java)

person qbait    schedule 26.08.2018    source източник


Отговори (1)


Според тази тема Не може да се подиграе с клас BufferedWriter в junit

Можете да се подигравате на Java IO класове (включително техните конструктори, така че бъдещите екземпляри също да се подиграват) с библиотеката JMockit, въпреки че вероятно ще се сблъскате с трудности като NullPointerException от конструктора Writer() (в зависимост от това как е направено подиграването и кое IO класове бяха подигравани).

Обърнете внимание обаче, че Java IO API съдържа много взаимодействащи си класове и дълбоки йерархии на наследяване. Във вашия пример класът FileWriter също вероятно ще трябва да бъде подиграван, в противен случай ще бъде създаден действителен файл.

Освен това използването на IO класове в кода на приложението обикновено е просто детайл на изпълнението, който може лесно да бъде променен. Можете да превключите от IO потоци към писатели, от обикновен IO към NIO или да използвате новите помощни програми на Java 8, например. Или използвайте IO библиотека на трета страна.

В крайна сметка, просто е ужасно лоша идея да се опитвате да се подигравате на IO класове. Още по-лошо е, ако (както е предложено в друг отговор) промените кода на клиента, за да имате Writers и т.н., инжектирани в SUT. Инжектирането на зависимост просто не е за такива неща.

Вместо това използвайте реални файлове в локалната файлова система, за предпочитане от тестова директория, която може да бъде изтрита след теста, и/или използвайте файлове с фиксирани ресурси, когато само четете. Локалните файлове са бързи и надеждни и водят до по-полезни тестове. Някои разработчици ще кажат, че "тестът не е единичен тест, ако засяга файловата система", но това е просто догматичен съвет.

person qbait    schedule 26.08.2018