Телеграмм чат группы proelixir страница 8062

parrot.ru

Рейтинг популярных групп и каналов

В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

pro.elixir

1129 membersпожаловаться на группу

2021 February 02

((

(fun () -> ()) in pro.elixir

Я вроде бы все описал :) Если SQL или NoSQL транзакции нельзя изолировать для каждого теста, тогда такие зависимости становятся Shared и это уже не подпадает под категорию unit тестов

а если нужно сменить базу будет на базу без изоляций. Тогда выходит всё переписать нужно?

источник

12:45пожаловаться #1

IK

Ihor Katkov in pro.elixir

а если нужно сменить базу будет на базу без изоляций. Тогда выходит всё переписать нужно?

Это, очевидно, повлечет за собой довольно масштабные изменения. Сложно представить use case, где нужно одномоментно слезть с Postgres на NoSQL и при этом не переписав кучу логики не только в тестах, но и в самом коде

источник

12:49пожаловаться #2

((

(fun () -> ()) in pro.elixir

Это, очевидно, повлечет за собой довольно масштабные изменения. Сложно представить use case, где нужно одномоментно слезть с Postgres на NoSQL и при этом не переписав кучу логики не только в тестах, но и в самом коде

а что если домен сделать чистым?

источник

12:50пожаловаться #3

IK

Ihor Katkov in pro.elixir

а что если домен сделать чистым?

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

источник

12:52пожаловаться #4

((

(fun () -> ()) in pro.elixir

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

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

источник

12:55пожаловаться #5

IK

Ihor Katkov in pro.elixir

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

> Значит то что вы тестировали не было юнитом
Это не так.

> Давайте я перефразирую "аличие базы в тестах это ок" - наличие определенных баз в тестах это ок
Да, это верно

источник

12:58пожаловаться #6

((

(fun () -> ()) in pro.elixir

не, ну вообще имеет смысл. Из-за высокой скорости разработки (относительно языков на которых я писал до elixir) в случае кардинальной смены архитектуры проще, наверное, переписать, чем сразу поддерживать систему для таких изменения. Я правильно понял идеологию Elixir?

источник

13:05пожаловаться #7

IK

Ihor Katkov in pro.elixir

нет, это не является идеологией, на сколько я понимаю :)

Есть ряд community стандартов, которые поддерживают определенный подход к юнит тестам по причинам, которые я описал выше

> в случае кардинальной смены архитектуры проще, наверное, переписать, чем сразу поддерживать систему для таких изменения
Почти наверняка, переписывание будет поэтапным в независимости от ЯП

источник

13:15пожаловаться #8

RK

Roman Kolesnev in pro.elixir

Еще наброшу. Проще писать не мокая БД. В случае постгри и ecto - там даже параллельные тесты можно поддерживать (sandbox adapter).

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

Мокая все подряд с самого начала лишь замедлишь разработку.

Дрочево на "идельно чистые юнит тесты" никому не нужно если оно не делает жизнь проще.

источник

13:29пожаловаться #9

AL

Anton Lapshin in pro.elixir

ecto в nosql в принципе не умеет. три с половиной калечных заброшенных адаптера это подтверждает. даже в activerecord рельсовом переход на ту же монгу с sql был пусть и проще, но тоже в деталях нетривиален, а в ecto с его подходом, кмк, вообще никак

источник

13:30пожаловаться #10

AL

Anton Lapshin in pro.elixir

> Дрочево на "идельно чистые юнит тесты" никому не нужно если оно не делает жизнь проще.

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

источник

13:31пожаловаться #11

LL

Lama Lover in pro.elixir

ecto в nosql в принципе не умеет. три с половиной калечных заброшенных адаптера это подтверждает. даже в activerecord рельсовом переход на ту же монгу с sql был пусть и проще, но тоже в деталях нетривиален, а в ecto с его подходом, кмк, вообще никак

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

источник

13:31пожаловаться #12

AL

Anton Lapshin in pro.elixir

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

источник

13:31пожаловаться #13

AL

Anton Lapshin in pro.elixir

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

не обновлявшийся с 2018, ага

источник

13:32пожаловаться #14

RK

Roman Kolesnev in pro.elixir

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

Я за интеграционные обеими руками, ес че)

источник

13:32пожаловаться #15

AL

Anton Lapshin in pro.elixir

Я за интеграционные обеими руками, ес че)

и я

источник

13:32пожаловаться #16

AL

Anton Lapshin in pro.elixir

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

источник

13:33пожаловаться #17

RK

Roman Kolesnev in pro.elixir

Просто пытался в пет-прожекте писать все юниты максимально в изоляции и понял, что в 90% случаев это бессмысленное дрочево которое делает код сложнее.

источник

13:33пожаловаться #18

AL

Anton Lapshin in pro.elixir

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

и это особенно актуально для языков типа руби

источник

13:34пожаловаться #19

LL

Lama Lover in pro.elixir

Просто пытался в пет-прожекте писать все юниты максимально в изоляции и понял, что в 90% случаев это бессмысленное дрочево которое делает код сложнее.

Когда один пишешь код, правила вообще совершенно другие

Для меня юнит-тесты, это как doctests 2.0. То есть там можно подсмотреть и на окружение, в котором должен код работать, как код должен вызываться, что код возвращает и всё такое.

Ещё юнит-тесты позволяют очень быстро и легко выявлять какие-нибудь простые ошибки из серии "забыл раскомментить код" и всё такое

источник

13:36пожаловаться #20