Cуть в том, что можно размышлять о этих частях по отдельности.
Это почти как выносить часть логики в функцию....
К тому же inputs и outputs становятся чётче и понятнее

козырный аргумент какой то)

Я знаю - с выносом логики в функцию сложно спорить 😂

щааааа

)))))))))

щаааааааа

ну вот приватный метод, ты бы вынес в отдельный файл?)

в отдельную функцию, и отдельно тестировал бы?)

@thekiba если мне память не изменяет именно этот вариант для тестирования приватных методов предлагает

я говорил, что если есть приватный метод, то это напрашивается на отдельный класс

Нет, приватный метод точно бы не тестировал отдельно.

Но тут проблема в другом - гонять всевозможные тест сценарии поведения Компонента через ДОМ - это через чур по нескольким причинам, а именно так желательно тестировать их - через ДОМ (можем углубиться здесь в нескольких моментах, но пока оставлю в стороне).

Поэтому лучше просто дать разнообразные данные компоненту, и убедиться что темплейт правильно работает. Потом потригерить кнопочки - и они тоже что-то отсылают. На этом тестирование темплейта заканчивается и множно переходить к более (1) быстрым (2) фокусированным (3) енкапсулированным тестам самой логики. 🙂

мисье

хочу заметить что вы соскачили

с вопроса про cognitive load)

да, тесты писать легче, отдельно для логики логики компонента, отдельно для шаблона компонента
с этим не спорю

Хорошее замечание 🙂
Cognitive load тоже - когда я разбираюсь с компонентом, я только задумываюсь о том ЧТО мне нужно. Когда пишу сервис, я задумываюсь КАК мне это получить, и КАК связать.

А когда приходишь в чужой сервис - ПОЧЕМУ это было сделано так)