должны ли модульные тесты быть тестами черного ящика или тестами белого ящика?

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

Это зависит.

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

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

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

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

Answer 2

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

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

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

Answer 3

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