Javascript-форум (https://javascript.ru/forum/)
-   Оффтопик (https://javascript.ru/forum/offtopic/)
-   -   Набить руку TDD (https://javascript.ru/forum/offtopic/50187-nabit-ruku-tdd.html)

melky 16.09.2014 06:51

Набить руку TDD
 
хай всем. обращаюсь к публике за мелкими идеями проектов (супер мелкими), где можно набить руку к подходу Test Driven Development. Т.е. какая-то мелкая задача с техническим описанием, что можно и чего нельзя. Так то оно всё понятно, но когда садишься за реальную задачу, то теряешься как-то...

Пока вот что нашел:
String Calculator

буду рад, если дополнительно ещё что-нибудь посоветуете :)

kobezzza 16.09.2014 10:32

Забей, это утопия. Никто нигде и некогда не использует TDD, т.к. это квинтэссенция контпродуктивности, а те кто говорит, что использует просто врёт, чтобы повыпендриваться :)

Я бы отнёс TDD к 100% покрытию кода, которое также невозможно в реальной жизни.
Тесты писать нужно, но TDD это перебор :)

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

l-liava-l 16.09.2014 10:34

console.log :cray:

Тесты писать жуть как лень, хотя одно время заморачивался

nerv_ 16.09.2014 10:39

Привет!

<label>I'm agree
    <input type="checkbox"/>
</label>
<div style="display: none;">Lisense</div>

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

Gozar 16.09.2014 16:21

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

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

melky 16.09.2014 16:39

Цитата:

Сообщение от kobezzza (Сообщение 330761)
Забей, это утопия. Никто нигде и некогда не использует TDD, т.к. это квинтэссенция контпродуктивности, а те кто говорит, что использует просто врёт, чтобы повыпендриваться :)

Я бы отнёс TDD к 100% покрытию кода, которое также невозможно в реальной жизни.
Тесты писать нужно, но TDD это перебор :)

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

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

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

Цитата:

Сообщение от Gozar (Сообщение 330875)
Кстати, чем концепция TDD отличается от обычного программирования?
.

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


Цитата:

Сообщение от nerv_ (Сообщение 330772)
Привет!

<label>I'm agree
    <input type="checkbox"/>
</label>
<div style="display: none;">Lisense</div>

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

благодарю :)

Gozar 16.09.2014 16:57

Цитата:

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

Долго сидишь? Ню, ню. А то у меня бывает день программа работает, а потом бабах и я узнаю об этом мире что-то новое. Эмулирование теста может занять 1 день :) Я называю это полубоевой сервер. Всплывающие баги просто невозможно предсказать, если не имеешь соответсвующих знаний, которых не может быть при первой встрече с новым багом.

А еще ошибка чаще всего не логируется, т.к. неизвестная :D

Мне думается, что ты добъешся каких-то результатов, вот только мне интересно каких? :D

melky 16.09.2014 17:05

Цитата:

Сообщение от Gozar
Мне думается, что ты добъешся каких-то результатов, вот только мне интересно каких?

пока что до упорной практики не дошло, но первые вздохи есть
Цитата:

Сообщение от Gozar
А еще ошибка чаще всего не логируется, т.к. неизвестная

они все такие ... сначала

Gozar 16.09.2014 17:09

Цитата:

Сообщение от melky
они все такие ... сначала

Я про логирование. Например браузер падает и ты не знаешь в какой момент, как отлогировать ошибку? Единственный способ, который я знаю - писать в файл. Допустим ты пишешь в файл и написал уже 5 Гб логов :) Главное писать в мелкие файлы, а не в один, тогда можно посмотреть последний, а не пытаться открыть 5 Гб файл. :)

Или допустим процесс идет 1 день и ты не знаешь, закончился он или зациклен. В программе возможно нет ошибки, ошибка в сканируемом объекте, а может и нет. Что по этому поводу говорит TDD?

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

WorM32 16.09.2014 17:22

Цитата:

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

Так пиши тесты на взаимодействие с GUI. Можно использовать тот же Jasmine или любой другой фреймворк для тестов.

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

kobezzza 16.09.2014 17:26

Цитата:

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

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

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

Цитата:

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

Цитата:

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

Цитата:

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

Gozar 16.09.2014 17:48

Цитата:

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

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

melky 16.09.2014 18:48

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

kobezzza 16.09.2014 19:28

Цитата:

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

Gozar 16.09.2014 19:35

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

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

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

WorM32 17.09.2014 09:11

Цитата:

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

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

Gozar 17.09.2014 10:07

WorM32,
КЭП?!

Safort 29.10.2014 21:14

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

kobezzza 29.10.2014 21:50

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

cyber 29.10.2014 22:04

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

Safort 29.10.2014 22:36

kobezzza,
а что-то другое пробовал? Почему именно Жасмин?

Safort 29.10.2014 22:45

cyber,
на том же Жасмине, например.

Safort 29.10.2014 22:49

cyber, вот небольшой обзор http://www.slideshare.net/kazanqacom...cript-24234210

kobezzza 29.10.2014 22:51

Цитата:

Сообщение от cyber (Сообщение 338300)
kobezzza, как и на чем писать тесты для ноды?)

Смотря какие тесты, если unit, то на том же Jasmine или любом другом модуле (кстати в состав ноды входит модуль для тестирования).

А если для тестирования клиент-сервера то phantom.js, zombie.js и т.д.

Для нагрузочных тестов тоже свои либы, в общем нужно понять что тестируешь, для начала :)

kobezzza 29.10.2014 22:52

Цитата:

Сообщение от Safort (Сообщение 338313)
kobezzza,
а что-то другое пробовал? Почему именно Жасмин?

До этого юзал qUnit. В Jasmine понравился синтаксис, вложенные модули и простота написания асинхронных тестов.

melky 29.10.2014 23:39

я в своем рабочем процессе для тестирования остановился на следующих инструментах для модульного тестирования:
  • Karma - для клиентской части
  • Mocha - для серверной части
  • Sinon + Chai в режиме should - для обеих частей :)

для системного тестирования - на ангуляре использовал Protractor, сейчас - хз. думаю попробовать Nightmare.

недавно начал пилить приложуху на реакте... со следующего проекта попробую выкинуть Karma нафиг - виртуальный DOM всё таки :)

Safort 30.10.2014 19:50

kobezzza, melky, спасибо за инфу, пока остановился на Jasmine.

melky 28.02.2015 16:53

немного дополню ... до чего я докатился :)

прошло время, я выкидываю karma как неэффективный инструмент (точнее, как медленный инструмент)

я использую в работе React, а он прекрасно работает в jsdom
получается, что для тестирования компонентов не нужен браузер. Gotcha!

в общем, теперь у меня такой тулсет. для серверной части и клиентской:

- фреймворк: Mocha. самый мощный инструмент что я видел. особо радуют xit, xdescribe, it.only, describe.only (вообще жесть)
- сами сравнения - Chai (в режиме should), Sinon (spy, stub) и Chai as promised (для красивого тестирования Promise)
- окружение: webpack (йохохо), rewire (иньекция переменных в модули. например, подменить вызов ORM на stub из sinon), mocha-loader (для запуска тестов mocha для файлов, которые должны обрабатываться webpack'ом) и isparta-instrumenter (для оценки покрытия ES6 кода)


Часовой пояс GMT +3, время: 11:08.