Насмешка над статическим методом - это всегда хрупкий подход. Если возможно, предпочтите использовать нестатический источник UUID, который затем можно легко смоделировать.
Например:
/**
* A source of new {@link UUID} instances.
*/
public interface UuidSource {
/**
* Returns a new {@link UuidSource} that generates UUIDs using {@link UUID#randomUUID}.
*/
public static UuidSource random() {
return UUID::randomUUID;
}
/**
* Returns a new {@link UUID} instance.
*
* <p>The returned value is guaranteed to be unique.
*/
UUID newUuid();
}
Затем вы можете добавить его в TestedClass
или иметь TestedClass
частного участника:
public class TestedClass {
private UuidSource uuidSource = UuidSource.random();
public UUID getUUID() {
return uuidSource.newUuid();
}
// etc.
}
Затем, чтобы протестировать его, вы можете либо иметь конструктор только для тестирования, чтобы разрешить инъекцию в фиктивном UuidSource
, либо вы можете напрямую заменить значение поля uuidSource
(либо расширив его видимость, либо используя отражение или что-то).
В качестве бонуса: это отделяет ваш фактический производственный код от UUID.randomUUID()
. Если позже вы решите, что вам нужно использовать UUID версии 2 (на основе datetime) или какую-то другую версию, а не случайные UUID, вы также можете легко изменить это в своем рабочем коде. Это то, что люди имеют в виду, когда говорят, что, делая ваш код более тестируемым, обычно улучшается общий дизайн.