Является ли тестирование модулей всегда белым ящиком? [Дубликат]
Это означает, что вы пытаетесь манипулировать тем, что имеет ссылку, но еще не инициализировано. Первое, что нужно сделать, это проверить каждый созданный экземпляр. Используйте контрольные точки, часы, проверяйте свои значения varibale. Следить за трассировкой стека и искать точные строки и столбцы, которые создают проблему
2 ответа
Я думаю, что эта статья Кента Бек , относящаяся больше к TDD, и модульное тестирование суммирует это довольно хорошо. В принципе, это зависит от того, как вы на самом деле пишете тесты *. Вот еще одна статья по этому вопросу , которая может помочь прояснить ситуацию.
* Если вы тестируете из своего приложения, то это whitebox. Если вы тестируете его так же, как аутсайдер сделает вызовы только для вашего публичного API, то это черный ящик.
-
1– Abdalrahman Shatou 22 July 2015 в 08:08
-
2– hellboy 10 November 2015 в 13:14
Обычными критериями для тестирования белого ящика являются путь выполнения и сенсибилизация структуры данных. Их иногда называют «тестирование филиалов», «тестирование путей», «тестирование потока данных». См. Википедию о тестировании белого ящика.
То есть, unit-test относится к уровню, на котором тест проходит в структуре системы, тогда как тестирование белого и черного ячеек относится к тому, на любом уровне подход к тестированию основан на внутреннем дизайне или только на внешней спецификации устройства.
Итак, если ваш блок-тест сенсибилизирует все пути выполнения и структуры данных в блоке, которые вы тестируют, то это тест с белым ящиком. Однако, если ваш блок не может сенсибилизировать большинство путей и структур данных устройства, он не может претендовать на звание «белого ящика».
Следует иметь в виду, что в некоторых организациях вызывается модульное тестирование white-box, независимо от того, основан ли блок-тест на дизайне устройства, а не на его API. Лучше не спорить с вашим боссом по этому вопросу.