Я уже писал об этом в комменте под видео «TDD - это круто! Разработка через тестирование и только!», но напишу ещё раз чуть подробнее. На самом деле, тесты - это не главное. Главное - это требования, о которых ты, кстати, здесь упомянул. Требования, проектная документация - вот, что запускает процессы написания кода. Код не пишется просто так, он пишется для ЧЕГО-ТО, чтобы решить какую-то задачу. А тесты - это просто утилиты, которые проверяют, что код соответствует требованиям. То есть они стоят посередине между требованиями и реализацией. Как на данный момент делаю я: 1. Сперва я генерирую проект с помощью написанного мною самим скрипта с созданием базовых файлов, инициализацией git'а и прочими подготовительными операциями. 2. Затем я заполняю файлик README (я программирую на JS). Этот файл всё равно надо заполнять, если выкладывать код куда-то. А тут - ты сразу начинаешь с него. Я пишу в нём то, что приложение делает, какие функции, какое API предоставляет, если это библиотека. В общем плане описываю каждую функцию, называя её сразу так, как нужно (возможно, название диктуется какой-то совместимостью с другой библиотекой, и тут ты сразу же этот момент учитываешь). Также на этом этапе рисуются схемы, если приложение сложное и тому подобное в папке со спецификацией и документацией. 3. Под каждую функцию пишу тест, который проверяет её работоспособность, убеждается, что она делает именно то, что требуется, возвращает правильные данные. Все тесты должны падать, потому что функции ещё не написаны. 4. И только потом пишу код приложения. Прикол в том, что большинство программистов делают всё наоборот, живя по принципу «Пойди туда, не зная куда, сделай то, не знаю что». И отсюда куча боли, страданий и потери времени: 1. Сперва большинство пишут, не понятно что, реализуют какие-то мутные представления о продукте, о которых бабка нашептала. 2. Пишут тесты, пытаясь сломать свой код. Хотя суть тестов на самом деле не в том, чтобы сломать код. Ломая код, ты делаешь его неуязвимым, закрываешь все мыслимые и немыслимые бреши, но это в большинстве случаев вообще не нужно. В большинстве случаев твоя функция просто никогда не получит не те данные, которые могли бы сломать её. И потому вкладывать силы в то, чтобы сделать её идеальной и неуязвимой, пройти все проверки - это пустая трата времени, в том числе времени в рантайме, где она будет перепроверять то, что итак надёжно, тратя впустую время процессора. Подлинная же суть теста в том, чтобы убедиться, что функция делает именно то, что от неё требуется в определённых рамках использования. В стандартном же пайплайне, когда после написания кода программистами, тестеры его ломают (не представляя в большинстве случаев, как он должен работать) - это полная ерунда, пустая трата времени и человеко-часов. И прикол в том, что в результате этой бессмысленной работы всё равно остаются странные косяки, потому что тестеры не знают, как работает приложение и не видят всевозможных нюансов, так как не они его писали. 3. И только потом уже пишется readme, описание проекта, документация и схемы. Хотя на самом деле нужно с этого и начинать - с того, что ты хочешь получить, с образа того, каким должно быть твоё приложение. И исходя из образа уже строить его. По-моему, только это - подход здорового человека - начинать с чёткой идеи, а не с аморфных, неясных представлений о том, что ты делаешь. Это как в строительстве домов. Никто не начинает сразу строить. Сперва делается проект, схемы, а только потом уже вкладываются силы и средства в реализацию. В программировании же почему-то люди не склонны действовать разумно. А ведь на самом деле программирование - это то же самое строительство, только строится здесь уже приложение из модулей и блоков кода. И для этого здания тоже нужен сперва проект.
Спасибо за такой раскрытый ответ. Особенно за то, что поделились тем, как строите свой процесс разработки, думаю, что это может быть многим полезно. > А тесты - это просто утилиты, которые проверяют, что код соответствует требованиям. То есть они стоят посередине между требованиями и реализацией. Тесты - это синтез кода и требований. Они рождаются в процессе борьбы кода с требованиями, тем самым решая это противоречие. Теперь код становится своего рода требованиями, более ярко это отражено в BDD. Еще раз большое спасибо! PS. Вы, как я понял, примерно по BDD и работаете. Просто без фреймворка.
@@kydavoiti я не соглашусь насчёт BDD. BDD - это попытка написать код через человекообразное описание бизнес-процесса. По-моему, это очень геморно. Мой же подход программистский. Программист уже понял, как надо реализовать бизнес-идею и описал функционал и требования к нему. А тесты уже тестируют данный функционал, который требуется от приложения. Тесты не связаны с бизнесом напрямую, но определённая связь, конечно, есть. Код - это не требование, это реализация требований. Например, требование - заказчику необходимо создать приложение, считающее сумму двух чисел. Описание проекта: "Приложение представляет из себя функцию sum, возвращающую сумму двух чисел". Тест к требованию: test('sum', () => { assert.equal(sum(2,2), 4) } Решение: function sum(a,b) { return a+b }.
Одной из причин перехода на безвентиляторный эйр на М1 у меня была как раз его безвентиляторность=тишина! До этого была прошка на интеле, даже после прочистки от пыли шумела так, что была слышна в кадре :)
Где про тдд можно почитать или посмотреть бесплатно если в этом нуль полный? По сети гуляет книга разоаботка на основе тестирования, но она 18 кажется года, что настораживает, впрочем для увчебных целей возможно и норм, но может что то поактуальней есть?
Книга, что я рекомендую в конце - годная ozon.ru/t/Dk2en3J Ещё есть хорошая по работе с legacy кодом, там тоже большой акцент на TDD (я с нее в него начал вкатываться) www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 Есть канал Continues Delivery, у него есть курс бесплатный (пробный, полагаю) какой-то про TDD, но я не смотрел его Я бы на год не смотрел, тут скорее про идею, а не про инструмент. PS. На русском эта тема вообще неоч раскрыта, надо над этим работать
@@kydavoiti Круто! Просто написать хороший тест это вообще -то не простая задача. Я сейчас по сути только в катываюсь в TDD и в тестирование и попрой прихожу к очень интересным тестам. Было бы всё таки интересно посмотреть на решение таких задач от про:)
Я уже писал об этом в комменте под видео «TDD - это круто! Разработка через тестирование и только!», но напишу ещё раз чуть подробнее.
На самом деле, тесты - это не главное. Главное - это требования, о которых ты, кстати, здесь упомянул. Требования, проектная документация - вот, что запускает процессы написания кода. Код не пишется просто так, он пишется для ЧЕГО-ТО, чтобы решить какую-то задачу. А тесты - это просто утилиты, которые проверяют, что код соответствует требованиям. То есть они стоят посередине между требованиями и реализацией. Как на данный момент делаю я:
1. Сперва я генерирую проект с помощью написанного мною самим скрипта с созданием базовых файлов, инициализацией git'а и прочими подготовительными операциями.
2. Затем я заполняю файлик README (я программирую на JS). Этот файл всё равно надо заполнять, если выкладывать код куда-то. А тут - ты сразу начинаешь с него. Я пишу в нём то, что приложение делает, какие функции, какое API предоставляет, если это библиотека. В общем плане описываю каждую функцию, называя её сразу так, как нужно (возможно, название диктуется какой-то совместимостью с другой библиотекой, и тут ты сразу же этот момент учитываешь). Также на этом этапе рисуются схемы, если приложение сложное и тому подобное в папке со спецификацией и документацией.
3. Под каждую функцию пишу тест, который проверяет её работоспособность, убеждается, что она делает именно то, что требуется, возвращает правильные данные. Все тесты должны падать, потому что функции ещё не написаны.
4. И только потом пишу код приложения.
Прикол в том, что большинство программистов делают всё наоборот, живя по принципу «Пойди туда, не зная куда, сделай то, не знаю что». И отсюда куча боли, страданий и потери времени:
1. Сперва большинство пишут, не понятно что, реализуют какие-то мутные представления о продукте, о которых бабка нашептала.
2. Пишут тесты, пытаясь сломать свой код. Хотя суть тестов на самом деле не в том, чтобы сломать код. Ломая код, ты делаешь его неуязвимым, закрываешь все мыслимые и немыслимые бреши, но это в большинстве случаев вообще не нужно. В большинстве случаев твоя функция просто никогда не получит не те данные, которые могли бы сломать её. И потому вкладывать силы в то, чтобы сделать её идеальной и неуязвимой, пройти все проверки - это пустая трата времени, в том числе времени в рантайме, где она будет перепроверять то, что итак надёжно, тратя впустую время процессора. Подлинная же суть теста в том, чтобы убедиться, что функция делает именно то, что от неё требуется в определённых рамках использования. В стандартном же пайплайне, когда после написания кода программистами, тестеры его ломают (не представляя в большинстве случаев, как он должен работать) - это полная ерунда, пустая трата времени и человеко-часов. И прикол в том, что в результате этой бессмысленной работы всё равно остаются странные косяки, потому что тестеры не знают, как работает приложение и не видят всевозможных нюансов, так как не они его писали.
3. И только потом уже пишется readme, описание проекта, документация и схемы. Хотя на самом деле нужно с этого и начинать - с того, что ты хочешь получить, с образа того, каким должно быть твоё приложение. И исходя из образа уже строить его. По-моему, только это - подход здорового человека - начинать с чёткой идеи, а не с аморфных, неясных представлений о том, что ты делаешь.
Это как в строительстве домов. Никто не начинает сразу строить. Сперва делается проект, схемы, а только потом уже вкладываются силы и средства в реализацию. В программировании же почему-то люди не склонны действовать разумно. А ведь на самом деле программирование - это то же самое строительство, только строится здесь уже приложение из модулей и блоков кода. И для этого здания тоже нужен сперва проект.
Спасибо за такой раскрытый ответ. Особенно за то, что поделились тем, как строите свой процесс разработки, думаю, что это может быть многим полезно.
> А тесты - это просто утилиты, которые проверяют, что код соответствует требованиям. То есть они стоят посередине между требованиями и реализацией.
Тесты - это синтез кода и требований. Они рождаются в процессе борьбы кода с требованиями, тем самым решая это противоречие. Теперь код становится своего рода требованиями, более ярко это отражено в BDD.
Еще раз большое спасибо!
PS. Вы, как я понял, примерно по BDD и работаете. Просто без фреймворка.
@@kydavoiti я не соглашусь насчёт BDD. BDD - это попытка написать код через человекообразное описание бизнес-процесса. По-моему, это очень геморно. Мой же подход программистский. Программист уже понял, как надо реализовать бизнес-идею и описал функционал и требования к нему. А тесты уже тестируют данный функционал, который требуется от приложения. Тесты не связаны с бизнесом напрямую, но определённая связь, конечно, есть.
Код - это не требование, это реализация требований.
Например, требование - заказчику необходимо создать приложение, считающее сумму двух чисел.
Описание проекта:
"Приложение представляет из себя функцию sum, возвращающую сумму двух чисел".
Тест к требованию:
test('sum', () => {
assert.equal(sum(2,2), 4)
}
Решение: function sum(a,b) { return a+b }.
Одной из причин перехода на безвентиляторный эйр на М1 у меня была как раз его безвентиляторность=тишина! До этого была прошка на интеле, даже после прочистки от пыли шумела так, что была слышна в кадре :)
Привет, я думаю давно о обновлении, но не доходят руки 😬
Склоняюсь к macmini, скорее всего. Он тоже тихий, несколько я знаю.
Где про тдд можно почитать или посмотреть бесплатно если в этом нуль полный? По сети гуляет книга разоаботка на основе тестирования, но она 18 кажется года, что настораживает, впрочем для увчебных целей возможно и норм, но может что то поактуальней есть?
Книга, что я рекомендую в конце - годная
ozon.ru/t/Dk2en3J
Ещё есть хорошая по работе с legacy кодом, там тоже большой акцент на TDD (я с нее в него начал вкатываться)
www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
Есть канал Continues Delivery, у него есть курс бесплатный (пробный, полагаю) какой-то про TDD, но я не смотрел его
Я бы на год не смотрел, тут скорее про идею, а не про инструмент.
PS. На русском эта тема вообще неоч раскрыта, надо над этим работать
класс спасибо
Давай видео с примерами тестов, у тебя очень классные примеры
Будет, проковыряем библиотеку какую открытую
Может быть сами попишем там тесты и код по TDD
@@kydavoiti Круто! Просто написать хороший тест это вообще -то не простая задача. Я сейчас по сути только в катываюсь в TDD и в тестирование и попрой прихожу к очень интересным тестам. Было бы всё таки интересно посмотреть на решение таких задач от про:)
на методики тестирования пишешь)
I also have an old intel MacBook for 200$)
welcome to the club boddy