Я уже писал об этом в комменте под видео «TDD - это круто! Разработка через тестирование и только!», но напишу ещё раз чуть подробнее. На самом деле, тесты - это не главное. Главное - это требования, о которых ты, кстати, здесь упомянул. Требования, проектная документация - вот, что запускает процессы написания кода. Код не пишется просто так, он пишется для ЧЕГО-ТО, чтобы решить какую-то задачу. А тесты - это просто утилиты, которые проверяют, что код соответствует требованиям. То есть они стоят посередине между требованиями и реализацией. Как на данный момент делаю я: 1. Сперва я генерирую проект с помощью написанного мною самим скрипта с созданием базовых файлов, инициализацией git'а и прочими подготовительными операциями. 2. Затем я заполняю файлик README (я программирую на JS). Этот файл всё равно надо заполнять, если выкладывать код куда-то. А тут - ты сразу начинаешь с него. Я пишу в нём то, что приложение делает, какие функции, какое API предоставляет, если это библиотека. В общем плане описываю каждую функцию, называя её сразу так, как нужно (возможно, название диктуется какой-то совместимостью с другой библиотекой, и тут ты сразу же этот момент учитываешь). Также на этом этапе рисуются схемы, если приложение сложное и тому подобное в папке со спецификацией и документацией. 3. Под каждую функцию пишу тест, который проверяет её работоспособность, убеждается, что она делает именно то, что требуется, возвращает правильные данные. Все тесты должны падать, потому что функции ещё не написаны. 4. И только потом пишу код приложения. Прикол в том, что большинство программистов делают всё наоборот, живя по принципу «Пойди туда, не зная куда, сделай то, не знаю что». И отсюда куча боли, страданий и потери времени: 1. Сперва большинство пишут, не понятно что, реализуют какие-то мутные представления о продукте, о которых бабка нашептала. 2. Пишут тесты, пытаясь сломать свой код. Хотя суть тестов на самом деле не в том, чтобы сломать код. Ломая код, ты делаешь его неуязвимым, закрываешь все мыслимые и немыслимые бреши, но это в большинстве случаев вообще не нужно. В большинстве случаев твоя функция просто никогда не получит не те данные, которые могли бы сломать её. И потому вкладывать силы в то, чтобы сделать её идеальной и неуязвимой, пройти все проверки - это пустая трата времени, в том числе времени в рантайме, где она будет перепроверять то, что итак надёжно, тратя впустую время процессора. Подлинная же суть теста в том, чтобы убедиться, что функция делает именно то, что от неё требуется в определённых рамках использования. В стандартном же пайплайне, когда после написания кода программистами, тестеры его ломают (не представляя в большинстве случаев, как он должен работать) - это полная ерунда, пустая трата времени и человеко-часов. И прикол в том, что в результате этой бессмысленной работы всё равно остаются странные косяки, потому что тестеры не знают, как работает приложение и не видят всевозможных нюансов, так как не они его писали. 3. И только потом уже пишется readme, описание проекта, документация и схемы. Хотя на самом деле нужно с этого и начинать - с того, что ты хочешь получить, с образа того, каким должно быть твоё приложение. И исходя из образа уже строить его. По-моему, только это - подход здорового человека - начинать с чёткой идеи, а не с аморфных, неясных представлений о том, что ты делаешь. Это как в строительстве домов. Никто не начинает сразу строить. Сперва делается проект, схемы, а только потом уже вкладываются силы и средства в реализацию. В программировании же почему-то люди не склонны действовать разумно. А ведь на самом деле программирование - это то же самое строительство, только строится здесь уже приложение из модулей и блоков кода. И для этого здания тоже нужен сперва проект.

@kydavoiti

11 ай бұрын

Спасибо за такой раскрытый ответ. Особенно за то, что поделились тем, как строите свой процесс разработки, думаю, что это может быть многим полезно. > А тесты - это просто утилиты, которые проверяют, что код соответствует требованиям. То есть они стоят посередине между требованиями и реализацией. Тесты - это синтез кода и требований. Они рождаются в процессе борьбы кода с требованиями, тем самым решая это противоречие. Теперь код становится своего рода требованиями, более ярко это отражено в BDD. Еще раз большое спасибо! PS. Вы, как я понял, примерно по BDD и работаете. Просто без фреймворка.

@-dubok-

11 ай бұрын

​@@kydavoiti я не соглашусь насчёт BDD. BDD - это попытка написать код через человекообразное описание бизнес-процесса. По-моему, это очень геморно. Мой же подход программистский. Программист уже понял, как надо реализовать бизнес-идею и описал функционал и требования к нему. А тесты уже тестируют данный функционал, который требуется от приложения. Тесты не связаны с бизнесом напрямую, но определённая связь, конечно, есть. Код - это не требование, это реализация требований. Например, требование - заказчику необходимо создать приложение, считающее сумму двух чисел. Описание проекта: "Приложение представляет из себя функцию sum, возвращающую сумму двух чисел". Тест к требованию: test('sum', () => { assert.equal(sum(2,2), 4) } Решение: function sum(a,b) { return a+b }.

Одной из причин перехода на безвентиляторный эйр на М1 у меня была как раз его безвентиляторность=тишина! До этого была прошка на интеле, даже после прочистки от пыли шумела так, что была слышна в кадре :)

@kydavoiti

11 ай бұрын

Привет, я думаю давно о обновлении, но не доходят руки 😬 Склоняюсь к macmini, скорее всего. Он тоже тихий, несколько я знаю.

класс спасибо

Где про тдд можно почитать или посмотреть бесплатно если в этом нуль полный? По сети гуляет книга разоаботка на основе тестирования, но она 18 кажется года, что настораживает, впрочем для увчебных целей возможно и норм, но может что то поактуальней есть?

@kydavoiti

11 ай бұрын

Книга, что я рекомендую в конце - годная ozon.ru/t/Dk2en3J Ещё есть хорошая по работе с legacy кодом, там тоже большой акцент на TDD (я с нее в него начал вкатываться) www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 Есть канал Continues Delivery, у него есть курс бесплатный (пробный, полагаю) какой-то про TDD, но я не смотрел его Я бы на год не смотрел, тут скорее про идею, а не про инструмент. PS. На русском эта тема вообще неоч раскрыта, надо над этим работать

на методики тестирования пишешь)

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

@kydavoiti

11 ай бұрын

Будет, проковыряем библиотеку какую открытую Может быть сами попишем там тесты и код по TDD

@idushi_k_reke

11 ай бұрын

@@kydavoiti Круто! Просто написать хороший тест это вообще -то не простая задача. Я сейчас по сути только в катываюсь в TDD и в тестирование и попрой прихожу к очень интересным тестам. Было бы всё таки интересно посмотреть на решение таких задач от про:)

I also have an old intel MacBook for 200$)

@kydavoiti

11 ай бұрын

welcome to the club boddy