Чи є шпигунство на перевіреному класі поганою практикою?

Я працюю над проектом, де внутрішні дзвінки класу звичайні, але результати багато разів прості. Приклад ( не реальний код ):

public boolean findError(Set<Thing1> set1, Set<Thing2> set2) {
  if (!checkFirstCondition(set1, set2)) {
    return false;
  }
  if (!checkSecondCondition(set1, set2)) {
    return false;
  }
  return true;
}

Писати одиничні тести для цього типу коду дуже важко, оскільки я просто хочу перевірити систему умов, а не реалізацію реальних умов. (Я роблю це в окремих тестах.) Насправді було б краще, якби я передав функції, що реалізують умови, а в тестах я просто надаю макет. Проблема такого підходу - галасливість: ми багато використовуємо дженерики .

Робоче рішення; однак, це зробити тестований об'єкт шпигуном та знущатися над дзвінками до внутрішніх функцій.

systemUnderTest = Mockito.spy(systemUnderTest);
doReturn(true).when(systemUnderTest).checkFirstCondition(....);

Стурбованість тут полягає в тому, що реалізація SUT ефективно змінюється, і може бути проблематично тримати тести в синхронізації з реалізацією. Це правда? Чи є найкраща практика уникати цієї загрози внутрішніх викликів методів?

Зауважте, що ми говоримо про частини алгоритму, тому розбиття його на кілька класів може бути не бажаним рішенням.

Одиничні тести повинні розглядати класи, які вони перевіряють, як чорні поля. Важливо лише те, що його публічні методи поводяться так, як очікується. Як клас досягає цього за допомогою внутрішніх державних та приватних методів, значення не має.

Коли ви відчуваєте, що неможливо створити змістовні тести таким чином, це знак того, що ваші заняття занадто потужні та роблять занадто багато. Вам слід розглянути можливість переміщення частини їх функціональності в окремі класи, які можна перевірити окремо.

Якщо findError()і checkFirstCondition()т. Д. Є загальнодоступними методами вашого класу, тоді findError()фактично є фасад для функціональності, який уже доступний в тому ж API. У цьому немає нічого поганого, але це означає, що ви повинні написати для нього тести, які дуже схожі на вже існуючі тести. Це дублювання просто відображає дублювання у вашому загальнодоступному інтерфейсі. Це не є підставою для того, щоб цей спосіб по-різному ставитися до інших.

Одиничні випробування повинні перевірити контракт; це для них єдина важлива річ. Тестування всього, що не є частиною договору, є не лише марною тратою часу, а й потенційним джерелом помилок. Кожного разу, коли ви побачите розробника, що змінює тести, коли він змінює деталі реалізації, дзвони тривоги повинні дзвонити; що розробник може (навмисно чи ні) приховувати свої помилки. Навмисне тестування деталей впровадження змушує цю шкідливу звичку, роблячи більш ймовірною маскування помилок.

Внутрішні виклики є детальною інформацією щодо впровадження і повинні представляти інтерес лише для вимірювання ефективності . Що зазвичай не є завданням одиничних тестів.

По-перше, мені цікаво, що важко перевірити на прикладі функції, яку ви написали? Наскільки я бачу, ви можете просто передати різні входи та перевірити, щоб переконатися, що повернуто правильне булеве значення. Що я пропускаю?

Що стосується шпигунів, то так зване тестування "білої коробки", яке використовує шпигунів та знущань, - це на замовлення більше роботи, а не тільки тому, що для написання так багато більше тестового коду, але будь-коли реалізація змінивши, ви також повинні змінити тести (навіть якщо інтерфейс залишається тим самим). І цей вид тестування є також менш надійним, ніж тестування в чорному ящику, тому що вам потрібно переконатися, що весь цей додатковий тестовий код є правильним, і хоча ви можете довіряти, що тести чорного блоку вийдуть з ладу, якщо вони не відповідають інтерфейсу Ви не можете довіряти цьому щодо зловживання макетами коду, оскільки іноді тест навіть не перевіряє багато реального коду - лише макети. Якщо макети невірні, велика ймовірність того, що ваші тести будуть успішними, але ваш код все-таки порушений.

Кожен, хто має досвід тестування у білій коробці, може сказати вам, що вони болять у дупі, щоб писати та підтримувати. У поєднанні з тим, що вони менш надійні, тестування в білій коробці просто набагато поступається в більшості випадків.