Улучшаем тесты, mutation testing и TDD

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

Хорошего просмотра, тестируйте классно, тестируйте сильно.

### Главы

00:00 Не покупайте mac
00:30 Начало
00:46 Почему я хочу поговорить об этом?
01:51 Почему важно писать тесты?
02:06 Чем занимаются разработчики?
02:41 Мы пишем код для пользователей
03:10 Тесты — это примерный пользователь
03:47 Аналогия с играми
04:43 Тесты должны улучшаться
06:02 Почему надо пытаться сломать тест?
07:16 Как я тестил раньше?
08:17 Сейчас
09:31 Плюсы подхода
09:44 А какие проблемы?
11:05 Mutation testing
12:44 У всего своя цена
14:22 TDD
17:55 Вывод

Подписывайтесь на канал и на ссылке ниже, там обсуждают правду:

[-dubok-]

Я уже писал об этом в комменте под видео «TDD — это круто! Разработка через тестирование и только!», но напишу ещё раз чуть подробнее.

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

1. Сперва я генерирую проект с помощью написанного мною самим скрипта с созданием базовых файлов, инициализацией git'а и прочими подготовительными операциями.
2. Затем я заполняю файлик README (я программирую на JS). Этот файл всё равно надо заполнять, если выкладывать код куда-то. А тут — ты сразу начинаешь с него. Я пишу в нём то, что приложение делает, какие функции, какое API предоставляет, если это библиотека. В общем плане описываю каждую функцию, называя её сразу так, как нужно (возможно, название диктуется какой-то совместимостью с другой библиотекой, и тут ты сразу же этот момент учитываешь). Также на этом этапе рисуются схемы, если приложение сложное и тому подобное в папке со спецификацией и документацией.
3. Под каждую функцию пишу тест, который проверяет её работоспособность, убеждается, что она делает именно то, что требуется, возвращает правильные данные. Все тесты должны падать, потому что функции ещё не написаны.
4. И только потом пишу код приложения.

Прикол в том, что большинство программистов делают всё наоборот, живя по принципу «Пойди туда, не зная куда, сделай то, не знаю что». И отсюда куча боли, страданий и потери времени:

1. Сперва большинство пишут, не понятно что, реализуют какие-то мутные представления о продукте, о которых бабка нашептала.
2. Пишут тесты, пытаясь сломать свой код. Хотя суть тестов на самом деле не в том, чтобы сломать код. Ломая код, ты делаешь его неуязвимым, закрываешь все мыслимые и немыслимые бреши, но это в большинстве случаев вообще не нужно. В большинстве случаев твоя функция просто никогда не получит не те данные, которые могли бы сломать её. И потому вкладывать силы в то, чтобы сделать её идеальной и неуязвимой, пройти все проверки — это пустая трата времени, в том числе времени в рантайме, где она будет перепроверять то, что итак надёжно, тратя впустую время процессора. Подлинная же суть теста в том, чтобы убедиться, что функция делает именно то, что от неё требуется в определённых рамках использования. В стандартном же пайплайне, когда после написания кода программистами, тестеры его ломают (не представляя в большинстве случаев, как он должен работать) — это полная ерунда, пустая трата времени и человеко-часов. И прикол в том, что в результате этой бессмысленной работы всё равно остаются странные косяки, потому что тестеры не знают, как работает приложение и не видят всевозможных нюансов, так как не они его писали.
3. И только потом уже пишется readme, описание проекта, документация и схемы. Хотя на самом деле нужно с этого и начинать — с того, что ты хочешь получить, с образа того, каким должно быть твоё приложение. И исходя из образа уже строить его. По-моему, только это — подход здорового человека — начинать с чёткой идеи, а не с аморфных, неясных представлений о том, что ты делаешь.

Это как в строительстве домов. Никто не начинает сразу строить. Сперва делается проект, схемы, а только потом уже вкладываются силы и средства в реализацию. В программировании же почему-то люди не склонны действовать разумно. А ведь на самом деле программирование — это то же самое строительство, только строится здесь уже приложение из модулей и блоков кода. И для этого здания тоже нужен сперва проект.

[tdigital]

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

[firstandlast]

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

[idushi_k_reke]

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

[flatmapper]

I also have an old intel MacBook for 200$)