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

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

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

Ответил выше.

Практика подсказывает, что даже самый упоротый тест можно смодулировать, но порой приходится городить такие адские фасады, что действительно 90% людей просто забивает, и я например не исключение :)

Может я что то не так понимаю, но ведь BDD - это подход к самому написанию тестов, а не философия разработки, как TDD, т.е. в таком случае BDD - это просто сахар над банальным тестом.

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

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

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

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

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

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

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

Работает, но это ОЧЕНЬ утомительно, когда я пытался практиковать TDD, то перестал чувствовать радость от программирование и понимал, что превратился в секретаршу :( Тут нужны стальные нервы и дисциплинированность. К тому же TDD сильно затягивает сроки, поэтому в компаниях его редко практикуют, или практикуют, но только в критически важных местах.

1. Пишу тесты на небольшие части программы, те, которые могут жрать память или еще что-то подобное.
2. Пишу тесты при проектировании fj элементов (см. п. 1)

Написание же тестов просто "потому", для меня странное занятие. С другой стороны попробуй попиши, может ты найдешь это важным, если у тебя конечно время есть :).

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

Руками тестировать должны тестировщики, а писать автоматические тесты должны разработчики)

WorM32,
КЭП?!

Я вот недавно начал разбираться с этим вашим тестированием и выбираю какую библу для этого использовать. Пока остановился на jasmine, mocha, chai.
Можете прорекламировать то, что используете?) Хотелось бы узнать + и - выбранной библиотеки.

Я юзаю Jasmine, всем доволен.

kobezzza, как и на чем писать тесты для ноды?)