[melky]

Так пиши тесты на взаимодействие с GUI

это e2e которые (selenium)? трудно начать разработку проекта с этих тестов. да и работают чёт медленно - 5 секунд на "пустышку-тест" и режима watch нет

Для автоматизации удобно юзать Karma и PhanthomJS. Тесты запускаются во время отправки коммита и отправка фейлится, если какой либо из тестов провалился.

уже но с chromeOnly (не фантомом)

осталось понять, как же эти тесты хорошо писать)

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

И не старайся покрыть весь код, т.к. это тоже бред и утопия. Вот к примеру в Collection сейчас более 1000 тестов, но это капля в море, т.к. для 100% покрытия всех-всех возможностей нужно примерно 1e6 тестов (число взято из комбинаторики).

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

понял, TDD слишком сильно давит

ну а вообще подход спроектируй интерфейс, напиши тест всех возможных вариантов применения, а уже потом делай реализацию - он работает ? если не во вред использовать - я имею в виду то, что число тестов (покрытие) меняется и обратно пропорционально уровню компонента (ниже уровень, больше тестов) ? как считаете?)

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