Должны ли модульные тесты быть тестами на черную коробку или тесты белой коробки?

Question

Скажем, у меня есть три метода, все очень похожи, но с разными типами ввода:

void printLargestNumber(int a, int b) { ... }
void printLargestNumber(double a, double b) { ... }
void printLargestNumber(String numberAsString, String numberAsString) { ... }

Все три используют одну и ту же базовую логику. Например: может double версия - единственная, которая сравнивает числа, а два других просто конвертируют свои входные данные в double.

Мы могли бы представить несколько различных модульных тестов: первый вход больше, во -вторых, больше, оба входа отрицательны и т. Д.

Мой вопрос

Если все три метода имеют полный набор тестов (черный ящик, так как мы не предполагаем, что реализация ядра одинакова)

или

Должен только double Версия будет тестирована тщательно, а два других протестировались слегка для проверки параметров (белое тестирование ящиков, так как мы знаем, что они имеют ту же реализацию, и она уже была протестирована в double тесты)?

Answer 1

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

Answer 2

Это зависит.

Как вы думаете, реализация может измениться? Если так, то перейдите с тестированием черного ящика.

Если вы можете гарантировать, что реализация не изменится с белой коробкой. Тем не менее, шансы на то, что вы сможете гарантировать, что это не на 100%.

Вы можете пойти на компромисс и провести некоторые из тестов черного ящика, особенно в граничных условиях. Однако написание тестов должно быть простым - поэтому с этой точки зрения нет оправдания нет выполняя полное тестирование черного ящика. Единственный ограничивающий фактор - это время, необходимое для запуска тестов.

Возможно, вам следует исследовать возможность проведения тестов параллельно.

Answer 3

Существует набор тестов, которые явно проявляют общественные интерфейсы. Я бы рассматривал их как к черным тестам.

Существует второй набор тестов, которые можно рассматривать как рассмотрение угловых случаев реализации. Это тестирование белой коробки и, несомненно, имеет место в модульном тесте. Вы не можете знать интересные пути без каких-либо знаний о реализации белой коробки. Я бы обратил особое внимание на корпус строки, потому что интерфейс допускает строки, которые могут не преобразовать чистое в удвоение, которые раздвигают границы точности и т. Д.

Буду ли я разрезать несколько углов в целочисленном случае? Я знаю, что я подтолкнул пути в двойном корпусе, вероятно, не должен, но вполне мог бы под временным давлением.