11

вот и разбивай чтобы каждый it тестировал только свои данные

не надо строить тесты против одной таблицы.

Я на 100% уверен что можно разбить.

я не буду вдаваться в твою бизнес логику но я уверен что можно разбить код + тесты чтобы тестировать минимум.

сейчас ты сделал тяп-ляп даже не подумав.

ахахах

if внутри it это шедевр

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

И на рельсах в том числе)

До этого с tdd/bdd встречался только в постах на медиуме

ну ты в общем неправильно тестируешь бизнес-логику.

сядь подумай и сделай нормально как время будет.

Только не затягивай.

До этого с tdd/bdd встречался только в постах на медиуме

что такое медиум?

medium.com

вроде

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

блжад

я не могу в твою бизнес логику ща вдаваться понимаешь?

Потому что тестируется не кусок кода, а результат выполнения строчек так 1500 этих кусков кода)

уже исходя из того что ты тестируешь в одном из тестов количество я уверен что можно вынести конкретно этот тест кейс отдельно.

С минимальными данными.

мб у тебя 1500 строк в одном классе?)

Потому что тестируется не кусок кода, а результат выполнения строчек так 1500 этих кусков кода)

вот именно, бей код на куски

Он и так разбит на куски

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

их будет проще тестировать.

Там имитируется действие пользователя "внести данные" до упора

Он и так разбит на куски

так их и тестируй)

Если что то сложно тестируется то почти всегда это кривой код/бизнеслогика.

Это ебучие турнирные таблицы)

Я на 100% уверен что можно упростить

ты просто не хочешь сесть и подумать.

Тяп ляп все умеют делать.

Упростить можно, я уверен, другое дело, что оно уже дважды упрощено

нет, оно вообще не упрощено

оно должно быть разбито на части

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

и по частям тестировтаься

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

Проще сказать так, что это не тот проект не за те деньги, где можно сидеть и улучшать)

ты в себя вкладываешься

если ты сможешь писать простые и хорошие абстракции в купе с хорошими тестами - тебе же самому будет проще, в том числе и мейнтейнить код.

В кратце суть: Есть турнирная таблица (непременно ебучая). Есть действие - внести данные. В зависимости от введенных данных и его текущего положения, игрока может кидать в самые очевидные и не очень части этой долбанной таблицы. В каждой группе должно быть ровно 2 игрока, групп в таблице дохуища. После того, как я много раз повторяю действие "ввести рандомные данные" (по сути, счет одного игрока и другого), пока не останется "незавершенных групп". Уже по итогу я смотрю, нет ли у меня групп с неверным числом игроков (!= 2), нет ли у меня групп с двумя игроками в одной ячейке, нет ли у меня групп, где два игрока сидят в одной ячейке. И самое веселое - проверяю, что победитель на самом деле победитель. Т.е., он либо выиграл все матчи в одной стадии, либо проиграл один раз в этой стадии и выиграл все свои матчи в другой стадии. Я бы рад это упростить, но реально уже не представляю, как это сделать.

А, збс

ща я без оплаты буду в твою бизнес-логику входить, ага.

Могу 0.5 балтики предложить :)

Не пью, да и суть не в этом.

Не думаю что кто то будет тратить значительное время на то чтобы войти в существенное количество бизнеслогики.

Плюс я не любитель спорта.

> Уже по итогу я смотрю, нет ли у меня групп с неверным числом игроков (!= 2) Неверный подход

верный подход это ЗНАТЬ когда у тебя могут появиться группы с неверным количеством игроков

и делать на это тест кейсы с минимальными данными.

> После того, как я много раз повторяю действие "ввести рандомные данные" (по сути, счет одного игрока и другого) Почему рандомные?

у тебя есть строго конкретные кейсы и тебе нужно проверить что там все ок.

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

зачем там рандом?

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

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

Вот и смотри в каких ситуациях они там могут появиться

Вариантов слишком много

и вообще почему именно два?

напиши минимум данных чтобы воспроизвести проблему.

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

ERROR: S client not available

Суть: есть код, который в зависимости от текущего положения игрока называет следующее его положение

Вот и делай минимум данных чтобы проверить что этот код работает верно

зачем тебе для этого вся турнирная таблица?

Сделал три игрока, запустил код, убедился что игрок три встал на второе место

вот это тестирование.

не надо тестировать против магических данных.

Они абсолютно ничего не говорят о монолите

это все реверсить потом все равно придется.

По хорошим тестам можно всю программу написать с нуля сохранив ВСЕ поведение.

и точно также прочитать и понять что там происходит. При магических данных которые проверяют что вот такие данные возвращают вот это - ничего не понятно.

У меня ща в проекте есть такого рода тесты. Думаешь я залезая в такой тест понимаю что то вообще о бизнеслогике? ни грамма.

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

Если не понятно - то это больше похоже на интеграционный тест.

Их должно быть имхо минимум.

Потому что они не говорят что именно сломалось, они говорят только приблизительно что вот такая фича отвалилась.

Это как бы страховка чтобы не пустить на продакшен абсолютно не рабочую фичу. Но по интеграционному тесту долго разбираться что сломалось.. По юнит тестам быстрее.

то что у тебя сейчас есть это больше на интеграционный тест похоже, и все эти 11 it скорее всего можно безболезненно объединить в один и дать ему название фичи.

Друзья, кто фулстак и хочет время от времени на проектную работу по простому финтеху?

простой финтех - это какой?

простой финтех - это какой?

хайпы

ну просто если там надо один API с другим поженить и по пути нарисовать красивых графиков - это одно

а если там в процессе нужно анализировать гигабайты сырых данных, то нужен R а не ruby)

или хотя бы питон, там вроде придумали всяких костыликов как в R

или хотя бы питон, там вроде придумали всяких костыликов как в R

Бигдата, бишбармак и машин лернинг

или хотя бы питон, там вроде придумали всяких костыликов как в R

python > ruby?)

mercedes benz > bmw?

python > ruby?)

Смотря для чего

для бигдаты скорее да.

mercedes benz > bmw?

скорее джип vs обычный автомобиль

у каждого свои плюсы и минусы