Набить руку TDD

[kobezzza]

мне просто надоело тратить время на сидение в отладчике и "клик-клик" тестинг и я хотел бы этот процесс ускорить

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

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

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

Кстати, чем концепция TDD отличается от обычного программирования?

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

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

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

то же самое относится и к BDD, полагаю?

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

[Gozar]

даже самый упоротый тест можно смодулировать

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

[melky]

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

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

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

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

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

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

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

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

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

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

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

[kobezzza]

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

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

[Gozar]

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

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

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

[WorM32]

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

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

[Gozar]

WorM32,
КЭП?!

[Safort]

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

[kobezzza]

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

[cyber]

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