Как я понял Руслан говорит про хрестоматийный тдд, как в учебнике, и там действительно предполагается что ты ешь слона по частям, причем очень маленьким частям. Ты пишешь типа

def test_my_sum():
  assert my_sum(0, 0) == 0

Запускаешь, падает - нет такой функции. Определяешь функцию, запускаешь, падает потому что None != 0.
Пишешь

def my_sum(a, b):
    return 0

Проходит.
Выдыхаешь.
Добавляешь assert на (0 + 1) == 1 и пишешь дальше. Получается тот самый red, green, refactor, repeat. Звучит интересно, но неизвестно, можно ли заставить себя так писать и насколько это вообще стоит того.

А то что ты написал это больше на бдд похоже, геркин и вот это вот все.

Самообман какой-то

Это проблема поддерживаемости тестов как таковых. Не важно по тдд они будут написаны или просто рядом.

А есть книга по TDD, где примеры его использования не находятся на уровне написания функции для складывания двух чисел? Вот что бы было нечто более сложное и реальное. Как вариант - Web API с авторизацией и всем что нужно. Вот это было бы интереснее поглядеть за развитием мысли автора в процессе написания этого. И что бы всё по честному, с самого нуля. Дабы не возникало ощущение, что автор лукавит, утверждая что вот прям такие тесты он с первого раза и написал (как в книжке про Django + TDD, которую упоминали ранее).

Ну вот чуть по сложнее пример, как раз книга, которую Руслан штудирует. Там потом и до тестов js на фронте доходит, и более менее комплексно на мой взгляд

Сам не читал эту книгу, но со слов Руслана , у него возникло ощущение, что его "наё...ют", т.к. он не понимает каким образом можно догадаться до написания таких тестов не написав ещё реального кода.

Мне кажется сказывается еще мало опыта работы с Django, там предполагается интуитивное понимание архитектуры, и что за чем следует

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

И правда читал на английском, там очень простой разговорный слог, поэтому трудностей не было

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

Имено так.

Ну а я не знаком с джангой.

Но это не змаменят логики "проверить запущен ли сервер перед началосм разработки"

пчёлы против мёда, то есть интернета?
вообще звучит крипово "навязывание javascript"

GitLab продолжает политику навязывания JavaScript
Игнорируя сообщения о проблемах, в которых запрашивается реализация возможности использовать GitLab без предоставления ему доступа к JavaScript, GitLab продолжает усиление привязки к JavaScript. Теперь сервер не отдаёт список файлов в виде HTML, а добавляет на страницу элемент с id "js-tree-list", в который элементы вставляются посредством JavaScript.

=)

А кто-то на bitbucket настраивал pylint? Но не просто через хуки, а так, что бы коммит не принимался сервером, если проверка fail.

Если делать через хуки, то коммит будет на сервере и проверка даст пост фактум. Настраивать пре коммиты в репозитории? Ну кто-то забудет и не настроит.

это что-то вроде гитхабовских чеков?

Не юзал не могу сказать