Набить руку TDD
хай всем. обращаюсь к публике за мелкими идеями проектов (супер мелкими), где можно набить руку к подходу Test Driven Development. Т.е. какая-то мелкая задача с техническим описанием, что можно и чего нельзя. Так то оно всё понятно, но когда садишься за реальную задачу, то теряешься как-то...
Пока вот что нашел: String Calculator буду рад, если дополнительно ещё что-нибудь посоветуете :) |
Забей, это утопия. Никто нигде и некогда не использует TDD, т.к. это квинтэссенция контпродуктивности, а те кто говорит, что использует просто врёт, чтобы повыпендриваться :)
Я бы отнёс TDD к 100% покрытию кода, которое также невозможно в реальной жизни. Тесты писать нужно, но TDD это перебор :) Хотя частный случай TDD имеет право на жизнь - это TDD перед фиксом бага, т.е. пишем тест, в котором баг должен исправится и после этого уже фиксим. |
console.log :cray:
Тесты писать жуть как лень, хотя одно время заморачивался |
Привет!
<label>I'm agree <input type="checkbox"/> </label> <div style="display: none;">Lisense</div> Сделай так, чтобы при установке флажка показывался скрытый контент. Если флаг снят, блок с описанием должен скрываться. |
Кстати, чем концепция TDD отличается от обычного программирования?
Может я что-то странное делаю, но чаще всего в коде, который я пишу либо невозможно сразу эмулировать адекватный тест, либо настолько сложно, что он становиться бессмысленным. |
Цитата:
то же самое относится и к BDD, полагаю? Цитата:
Цитата:
|
Цитата:
А еще ошибка чаще всего не логируется, т.к. неизвестная :D Мне думается, что ты добъешся каких-то результатов, вот только мне интересно каких? :D |
Цитата:
Цитата:
|
Цитата:
Или допустим процесс идет 1 день и ты не знаешь, закончился он или зациклен. В программе возможно нет ошибки, ошибка в сканируемом объекте, а может и нет. Что по этому поводу говорит TDD? Представляю себе веселых финских гугловцев, которые сидят и ржут, - а-ха-ха-ха, мы отсканировали 500 терабайт, и неверно создали линкование, ахаха, теперь это гора неразборного мусора, надо было TDD сделать из 500 машин, хоу-хоу-хоу :) |
Цитата:
Для автоматизации удобно юзать Karma и PhanthomJS. Тесты запускаются во время отправки коммита и отправка фейлится, если какой либо из тестов провалился. |
Цитата:
И не старайся покрыть весь код, т.к. это тоже бред и утопия. Вот к примеру в Collection сейчас более 1000 тестов, но это капля в море, т.к. для 100% покрытия всех-всех возможностей нужно примерно 1e6 тестов (число взято из комбинаторики). Фиксировать тестами нужно уже финальный функционал на предмет основных фич, но самое главное, что действительно очень важно: когда фиксишь баг, то обязательно напиши тест, чтобы в будующем этот баг не вернулся бумерангом. Цитата:
Цитата:
Цитата:
|
Цитата:
|
Цитата:
Цитата:
осталось понять, как же эти тесты хорошо писать) Цитата:
ну а вообще подход спроектируй интерфейс, напиши тест всех возможных вариантов применения, а уже потом делай реализацию - он работает ? если не во вред использовать - я имею в виду то, что число тестов (покрытие) меняется и обратно пропорционально уровню компонента (ниже уровень, больше тестов) ? как считаете?) про покрытие понял - гнаться не стоит.. тут по-моему уже сам инстинктивно понимаешь, нужен тест для ветвления или нет про баги усвоил - по-моему, один из самых лучших случаев использования тестов |
Цитата:
|
1. Пишу тесты на небольшие части программы, те, которые могут жрать память или еще что-то подобное.
2. Пишу тесты при проектировании fj элементов (см. п. 1) Написание же тестов просто "потому", для меня странное занятие. С другой стороны попробуй попиши, может ты найдешь это важным, если у тебя конечно время есть :). По поводу тестирования у меня мнение, что разрабатывать должен один, а тестировать другой. Т.к. разработчик действует согласно своему мышлению и тесты его будут заведомо пристрастными. Для теста нужен ещё один взгляд. Обычно всплывает много интересного при тестах другим человеком, даже то, что в голову не могло прийти. |
Цитата:
|
WorM32,
КЭП?! |
Я вот недавно начал разбираться с этим вашим тестированием и выбираю какую библу для этого использовать. Пока остановился на jasmine, mocha, chai.
Можете прорекламировать то, что используете?) Хотелось бы узнать + и - выбранной библиотеки. |
Я юзаю Jasmine, всем доволен.
|
kobezzza, как и на чем писать тесты для ноды?)
|
kobezzza,
а что-то другое пробовал? Почему именно Жасмин? |
cyber,
на том же Жасмине, например. |
cyber, вот небольшой обзор http://www.slideshare.net/kazanqacom...cript-24234210
|
Цитата:
А если для тестирования клиент-сервера то phantom.js, zombie.js и т.д. Для нагрузочных тестов тоже свои либы, в общем нужно понять что тестируешь, для начала :) |
Цитата:
|
я в своем рабочем процессе для тестирования остановился на следующих инструментах для модульного тестирования:
для системного тестирования - на ангуляре использовал Protractor, сейчас - хз. думаю попробовать Nightmare. недавно начал пилить приложуху на реакте... со следующего проекта попробую выкинуть Karma нафиг - виртуальный DOM всё таки :) |
kobezzza, melky, спасибо за инфу, пока остановился на Jasmine.
|
немного дополню ... до чего я докатился :)
прошло время, я выкидываю 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. |