а юнит тесты

https://timsdevblog.wordpress.com/2015/03/30/kent-beck-on-tdd/

/thread

я тоже такое нагуглил. А своими словами?

Ты тупой и тебе надо перевести?

ну ОК, то что когда я пишу тесты после кода, глядя в код и когда мои тесты пляшут от этого кода - то это white box тесты.

Если я пишу тесты ДО кода, то это блекбокс тесты.

А бывает ли, что я пишу юнит тесты после кода, но игнорируя структуру кода? Типа у меня только спецификация, с точки зрения юзера. Т.е. бывают ли блек бокс тесты после кода?

Тут дело не в до или после. При настоящем блекбоксе ты ничего не знаешь о коде, кроме интерфейса, как будто сорцов нет вовсе. А когда начинаются всякие стабы и моки, то какой уж тут блекбокс.

А когда начинаются всякие стабы и моки, то какой уж тут блекбокс

серенький такой. ты можешь все так же ничего не знать о том, как себя ведет модуль under test (то есть white), но знать общую структуру системы (то есть black). термин gray box такие ситуации в принципе покрывает

Если я пишу тесты ДО кода, то это блекбокс тесты.

не обязательно. ты можешь делать тесты заранее зная, какая структура мождуля у тебя будет. но да, в общем случае тесты в TDD - блэкбоксовые.

А бывает ли, что я пишу юнит тесты после кода, но игнорируя структуру кода? Типа у меня только спецификация, с точки зрения юзера. Т.е. бывают ли блек бокс тесты после кода?

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

т.е. грубо говоря юнит тесты можно писать для функций, исходные тексты которых у тебя отсутствуют. Или ты не смотришь в тело фунцкий, а смотришь только на DOC-хидеры. И это будет называться блек бокс тестами.

ОК?

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