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

в сентри есть breadcrumbs, которые намного полезней просто логов

http://amir.rachum.com/blog/2017/03/03/generator-cleanup/ кстати, сам пост

в сентри есть breadcrumbs, которые намного полезней просто логов

Чем они намного полезнее обычных структурированных логов?

структурированные норм

Ну так мы не про дебаг принтэфами говорим

какой-нибудь ELK тоже неплохой вариант

Всем привет! Объединяем VR разработчиков https://t.me/vr_developers

что скажете по поводу написания тестов?

тесты нужны, особенно там где бизнес-логика, генерить много поломанного JSON имхо так себе занятие

А я скажу, что тдд работает

А я скажу, что тдд работает

Так же как и социализм

:)

какую СИ посоветуете?

gitlab ci, если гитлаб уже есть :)

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

который проходит тесты и ничего больше?

потом сам сидишь и думаешь, неужели вот эта задача действительно полностью решается в 20 строк кода

если оно проходит все те тесты, которые ты смог придумать, то оно сможет все, что ты от него хочешь

естессно надо уметь видеть всякие граничные условия

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

ну так когда ты поставил задачу нормально так, что смог ее описать в тдд с более-менее конкретными тестами, ты уже большую часть работы выполнил

то есть чтобы пройти тест надо сначала вернуть захардкоженную константу, а уже потом (не ломая теста) исправить это

ну да

это из разряда "я еще пока не знаю, какой мне надо написать код, но интерфейс работы с ним должен быть вот таким"

да, речь идет об отдельных юнитах, интеграция это все-таки сложнее

тесты это неявное описание системы через требования, код - явное через реализацию

да. Но тесты это и еще документация по использованию

Код тоже :)

и некоторая страховка, что код действительно себя ведет так, как написано в тестах

еще один хороший подход - REPL-driven development

когда ты пишешь куски кода и тут же в шелле проверяешь

но тут беда, что у тебя не сохраняется эта страховка на будущее, когда ты будешь вносить правки в этот код

ну да, в этом случае через тесты лучше

ну вобщем да, у меня мозг достаточно хорошо усвоил TDD by example и я уже закоренелый фанатик 8)

еще потом начинаю говорить про Transformation Priority Premise

еще до того, как я первый раз услышал про тдд, я уже любил самостоятельно писать тесты, чтобы видеть, что там получается. И тогда же мой тогдашний начальник говорил что-то вроде "прежде чем начинать писать код, надо понять, как ты определишь, что ты все написал"

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

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

и у тебя получается, что поддержка превращается в переписывание 20 строк тестов на 1 строчку кода

особенно если ты занимаешься тем, что мокаешь окружение, проверяешь, че сколько раз вызывается, вот это все

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

Тогда это не тдд

но тут уже наверно я не обладаю нужным опытом - ни разу пока (к счастью) не сталкивался с таким бизнесом

почему же?

почему же?

Если тест не проверяет логику, можно сказать его нет

тдд. Сначала тесты, потом код.

без тестов нет кода

но без согласования с бизнесом тестов тоже нет

Я понял, но если тест "размытый" то можно сказать его нет

размытого теста тоже нет

А бизнес говорит "сделай пока как-нибудь так, мы тут посмотрим и переделаем позже"

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

ну вот я говорю, я с таким в жизни не сталкивался.

и некоторая страховка, что код действительно себя ведет так, как написано в тестах

Да, вот это меня больше заботит на данный момент

Тут ещё мне кажется важно, что если тв пишешь с нуля вообще то там еще сложнее :)

а, еще

переписывать тесты потому, что "а, не, я сделаю интерфейс по-другому" лично меня не сильно напряжет

хотя да, если тестов много, то это много писанины для изменения одной строки кода

но тут стоит вспомнить о том, что тесты это тоже полноценный код. И их тоже не надо писать методом копипасты

Ну то есть тебе говорят, есть входные данные, пока они выглядят так (хаос), и вот на выходе нужно получить что-то такое (жесть). Ну а внутри тв сам как-нибудь разберись. Ты делаешь, через 3 дня это все меняется, когда все готово тебе ставят новую задачу: поменять выходные данные, дописать туда ещё что-то, добавить ещё функционал, и переделать часть старого.

И как бы ты будешь писать овер 100+ тестов каждые 2 дня?

тесты не пишутся в отрыве от кода

тесты не пишутся в отрыве от кода

Я ж говорю, код меняется каждые 2 дня

поменялись входные данные - надо писать другой код для анализа входных данных. Не поменялась внутренняя логика - код для внутренней логики не меняется

Я не про дописывание функций и методов, я про случай когда ты с нуля строишь сервис

писать код одновременно с тестами это не +100% к работе.

Какбы rgr

это кажется, что "если ты кроме кода еще и тесты пишешь, то ты пишешь в 2 раза больше"

ERROR: S client not available

писать код одновременно с тестами это не +100% к работе.

Часто это может быть +150% имхо

не, нифига

Народ

Посоветуйте чтиво по селениуму

я же говорю, у меня по тдд сам код получается крайне компактный и очевидный

я потом встаю от компа и думаю "не, ну я думал это будет сложнее, чем 20 строк кода"

Посоветуйте чтиво по селениуму

Документация?

Нет

Литература

http://www.obeythetestinggoat.com/pages/book.html#toc

там чувак вроде селениумом пользуется

Спасиб

BTW а как в ТДД ты мокаешь базу?

Там же ещё миграции, например

есть разные варианты

Или по ходу дела нужно ещё табличку добавить

Или дропнуть

первый - выделить базу в отдельный юнит и мокать его

Ну интерфейсом к юниту, ага

И это получается тебе нужно видеть наперёд на месяц

второй - использовать готовые решения для мока чего-либо

например для монги есть mongo-mock

мы кстати БД в тестах с нуля каждый раз накатываем.

миграции по тдд тоже делаются на самом деле

со всеми миграциями.

миграции по тдд тоже делаются на самом деле

Ужс

да, делать тестовую базу тоже можно, но это не совсем юнит тесты - или юнит тесты для твоего юнита работы с базой

а так это как раз интеграционные/функциональные тесты

которые я лично предпочитаю писать на чем-то более высокоуровневом. В случае питона беру behave

Ребята, как в nginx в location указать например /uploads/ Чтобы раздавал все папки из uploads кроме например одной ?

Думаю к каждой папке прописывать отдельный location не очень