Я пишу следующий класс:Предоставление частных частных методов тестирования?
public class MyClass{
private final MyAnotherClass[][] anotherClasses;
public MyClass(//args){
//initialization
}
//...
}
Я хотел бы проверить этот класс, но не хотелось бы, чтобы предоставить какие-либо методы, разоблачающие его iternal состояние (anotherClasses
массива в данном случае). Тест будет проверять состояние массива, поэтому мы должны получить к нему доступ.
ли это рассматривать в качестве хорошей практики, чтобы обеспечить способ, скажем
MyAnotherClass[][] getAnotherClasses(){
retun anotherClasses;
}
с package-private
видимостью использовать его только для тестирования? Я немного не уверен в этом. Мы вводим некоторую раздражающую связь между классом и его тестом ...
Возможно, есть лучший подход, чтобы справиться с этим?
Тестирование должно проверять только внешнее поведение тестируемого класса. Если вы замените двойной массив какой-либо другой структурой данных, которая более эффективно даст тот же результат, вам не нужно будет переписывать тесты, пока это дает тот же результат. Если вы будете полагаться на внутреннее состояние в своих тестах (не очень хорошая идея по причинам, которые я только что изложил), вы можете также использовать отражение, чтобы получить этот массив. – hexafraction
Отражение может быть –
@hexafraction true для данного конкретного случая, но часто случается, что общедоступные методы класса недостаточно мелкие, чтобы обеспечить хорошее модульное тестирование. – CPerkins