AnyString() как параметр для модульного теста

Question

Мне нужно иметь дело с устаревшим приложением, которое не имеет тестов. Поэтому, прежде чем начинать рефакторинг, я хочу убедиться, что все работает так, как есть.

Теперь представьте себе следующую ситуацию:

public SomeObject doSomething(final OtherObject x, final String something) { 
    if(x == null) throw new RuntimeException("x may not be null!"); 
    ... 
} 

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

Так что я сделал это

@Test(expected = RuntimeException.class) 
public void ifOtherObjectIsNullExpectRuntimeException() { 
    myTestObject.doSomething(null, "testString"); 
} 

Теперь это работает конечно.

Но вместо «testString» я хотел бы передать случайную строку.

Так что я попытался с:

Но это не допускается, так как я получаю

org.mockito.exceptions.misusing.InvalidUseOfMatchersException:. ... Вы не можете использовать аргумент matchers вне проверки или stubbing

Я понимаю смысл этого, но мне интересно, могу ли я все же сделать то, что хочу, без параметризации моего теста или тому подобного. Единственными библиотеками, которые я могу использовать, являются Junit, AssertJ, Mockito и Powermock.

Любые идеи?

Answer 1

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

Итак, почему бы не попробовать тестирование с помощью случайной строки? Мой личный фаворит в таком сценарии: java.util.UUID.randomUUID().toString(). Это будет практически всегда генерировать новую строку, которая раньше никогда не использовалась для вашего теста.

Я также хотел бы добавить, что если вы пишете тесты для своего класса SomeObject, вам следует избегать насмешек над поведением SomeObject. Из вашего примера, вы не совсем это делали, но похоже, что вы можете спуститься по этому маршруту. Откажитесь от зависимостей реализации, которую вы пытаетесь протестировать, а не самой реализации! Это очень важно; иначе вы на самом деле ничего не тестируете.

Answer 2

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

Answer 3

Испытания должны быть детерминированными. Использование случайных значений в тесте затрудняет воспроизведение поведения при отладке неудавшегося теста. Я предлагаю вам просто создать константу String для теста, например "abcdefg".

Answer 4

Вы смешиваете концепции здесь.

Все эти помощники «насмешливо», как anyString() предназначены для использования при настройке макет объекта.

Но когда вы проверяете свой код тестирования:

@Test(expected = RuntimeException.class) 
public void ifOtherObjectIsNullExpectRuntimeException() { 
    myTestObject.doSomething(null, "testString"); 
} 

вы найдете: нет абсолютно никаких насмешливый участие в этом тесте. Вы просто не можете использовать эти звонки Mokito в этом месте; потому что «в этом месте нет Мокито».

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

Последняя подсказка: есть java.lang.Objects И этот класс имеет хорошую проверку на нуль, так что мой код продукции только выглядит как

public SomeObject doSomething(final OtherObject x, final String something) { 
    Objects.requireNonNull(otherObject, "otherObject must not be null"); 
    Objects.requireNonNull(something, "something must not be null"); 

Только разницы нет: требует ... броски NullPointerExceptions

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

EDIT на комментарий о том, тест, чтобы проверить наличие возможных изменений в будущем: вы не должны делать это:

1. В определенной степени, как проверяется ваш вклад деталь реализации. Вы не проверяете детали реализации. Другими словами:
2. Ваш метод имеет определенный контракт (который вы, например, указываете неофициально, написав javadoc, который говорит, что «вызывает NPE на нулевом вводе»). Ваши тесты должны подтвердить точно, что текущий договор. И контракт заключается в следующем: выбрасывает, если первый аргумент равен null.

И, возможно, другая точка зрения; как я все еще думаю, что вы тратите свое время здесь! Вы должны убедиться, что все ваши интерфейсы понятны, понятны и просты в использовании. То, что они позволяют пользователям вашего кода делать правильные вещи легко; и препятствовать ему делать неправильные вещи. Вот на что вы должны обратить внимание - качество ваших интерфейсов в целом! Итак, вместо того, чтобы беспокоиться о том, как вы могли бы написать тест на возможные будущие изменения; просто убедитесь, что ваша база кода в целом согласована.