VS
White box тесты при рефаче придётся выкидывать
Size: a a a
2021 June 11
SP
ой не начинай про white box...
DT
Ну и пусть) главное задача будет выполнена
DT
Потом и тесты норм переписать можно
VS
Чувство на душе останется неприятное)
SP
white box тесты это антипаттерн. Точка. Просто их быть не должно.
То что ты в "тесте" зависимость подставляешь - это не значит что ты "открываешь" ящик. Ты просто предоставляешь зависимость. Ровно так же как в любых других тестах. Никакой разницы. Если ты детали реализации в тесты добавляешь это твои проблемы
То что ты в "тесте" зависимость подставляешь - это не значит что ты "открываешь" ящик. Ты просто предоставляешь зависимость. Ровно так же как в любых других тестах. Никакой разницы. Если ты детали реализации в тесты добавляешь это твои проблемы
DT
Нет, если ты осознаешь что ты делаешь и зачем)
SP
box черный или там белый или зеленый - это интерфейс, контрак. Все. "дублирование реализации" это плохо потому что ты реально ничего не тестишь. Но это не значит что юнит тесты должны быть такими.
SP
чаще это проблемы дизайна системы и "лень" - вроде "у меня есть зависимость с 100 методами и я застаблю только один и еще сделаю ассерт что он вызвался" - эт просто про хуевые тесты
SP
лечится такое - ручные фэйки. заставят прописать поведение для всех 100 методов и понять что "наверное мне надо дробить интерфейс"
VS
Ну так ящик может быть разного уровня. От e2e теста до 2-3 классов.
SP
и на любом уровне у тебя есть зависимости и на любом уровне ящик остается ящиком
SP
нет разницы подменяешь ты пэймент гейтвей на сэндбокс для E2E. подменяешь ты внешний сервис на мок сервер в компонентых тестах или предоставляешь ли ты заглушку в юнит тесте.
SP
есть контракты. Ты реализуешь их.
SP
люди просто не оч понимают что такое контракт
VS
Ну типа при e2e ты зависишь от якорей в DOM например. Реализации можешь менять, как перчатки, тесты менять не придётся.
Другое дело взять мелкий модуль на 2-3 класса. Там при изменении реализации может придётся попрощаться с тестами.
Другое дело взять мелкий модуль на 2-3 класса. Там при изменении реализации может придётся попрощаться с тестами.
VS
Там решил, что у меня модули неправильно поделены, решил по другому поделить - пока тесты. Это к тому, что ящики бывают разные
DT
Такой вариант. Я пишу штуку (агрегат whatever) для write части. У него контракт только для собственно изменения (логично). Как мне ассертить что что-то произошло? Расширять контракт чтением ради тестов или хукаться рефлексией?)
SP
при изменении реализации - нет. при изменении контрактов - возможно. Но кто мешает делать систему таким образом что бы контракты не менялись и просто появлялись новые)
SP
на абстрактных конях сложно + у меня обычно читкод в виде доменных ивентов, которые являются частью контракта.