@scala_ru

Страница 7 из 1499
 
Юрий
19.05.2016
12:14:17
просто альтеративный вариант - запускать на каждый тест контейнер. А это намного медленнее

 
Alexandr
19.05.2016
12:14:19
И так далее

 
Юрий
19.05.2016
12:14:31
какой, например?

 
Alexandr
19.05.2016
12:14:42
Какой угодно

Google
 
Юрий
19.05.2016
12:14:48
ну например

 
Alexandr
19.05.2016
12:15:21
Который FS юзает

 
Файловую систему

 
Юрий
19.05.2016
12:15:44
просто эта фраза про "кучу" исключений ничем не подкреплена. Делим тесты на две группу - одна может выполнятся параллельно, другая нет

 
какие еще тут могут быть варианты?

 
какая третья группа?

 
Igor
19.05.2016
12:16:37
какая третья группа?
не могут выполняться ни последовательно, ни паралельно

 
Юрий
19.05.2016
12:16:55
не могут выполняться ни последовательно, ни паралельно
Это как, простите?

 
Igor
19.05.2016
12:17:02
фейлятся

 
Юрий
19.05.2016
12:17:30
эээ, что?

 
Alexandr
19.05.2016
12:17:45
Не третья группа. Будет куча определений, что "тесты, у которых выполняется условие X, надо запускать последовательно, тесты, у которых выполняется условия Y, надо запускать последовательно, тесты, у которых выполняется условия XYZC, надо запускать последовательно..."

 
Юрий
19.05.2016
12:18:30
Не третья группа. Будет куча определений, что "тесты, у которых выполняется условие X, надо запускать последовательно, тесты, у которых выполняется условия Y, надо запускать последовательно, тесты, у которых выполняется условия XYZC, надо запускать последовательно..."
Я говорил исключительно про возможность запуска тестов параллельно.

 
булевый флаг, вместо "кучи определений"

Google
 
Vyatcheslav
19.05.2016
12:19:28
ну или просто анноташка

 
Alexandr
19.05.2016
12:19:43
А я имел в виду виды тестов, для которых должно делаться это исключение

 
Юрий
19.05.2016
12:19:51
ну это детали реализации, в каждом тестовом фреймворке по разному этот флаг можно задать

 
в scalatest можно выделять тесты в группы

 
и запускать все из группы, или все не из группы

 
Alexandr
19.05.2016
12:20:37
Чтобы новый программист потом понял, в какую именно группу помещать тот или иной тест, ему придется проштудировать кучу правил

 
Vyatcheslav
19.05.2016
12:21:24
ну вот у нас получается 2 вида тестов: одни изолированные (работают с изолированными данными и могут выполняться параллельно), другие нет (могут повлиять на работу других тестов). Какие еще тут могут быть виды :)

 
Юрий
19.05.2016
12:21:33
А я имел в виду виды тестов, для которых должно делаться это исключение
Программист должен понимать, возможно ли запустить два таких теста паралельно на одной тестовой базе. Если можно - то в параллельную группу. Если нельзя - то в последовательную.

 
Борис
19.05.2016
12:23:48
Так или иначе сделать можно все, интересней подумать как сделать это проще

 
Alexandr
19.05.2016
12:24:31
» 2 вида тестов: одни изолированные » (работают с изолированными данными » и могут выполняться параллельно), другие нет Это не виды, это группы) А виды это, например: 1. Тесты, которые делают специфичные запросы к БД, которые могут затронуть другие записи, потому что мы не хотим очищать БД после каждого теста. 2. Тесты, которые юзают общую файловую систему, потому что мы не хотим поднимать для каждого теста контейнер. И т.д.

 
Борис
19.05.2016
12:25:26
А на сколько долго запускать контейнер с бд, я просто с виртуализацией и контейнеризаций очень плохо знаком

 
Юрий
19.05.2016
12:25:33
» 2 вида тестов: одни изолированные » (работают с изолированными данными » и могут выполняться параллельно), другие нет Это не виды, это группы) А виды это, например: 1. Тесты, которые делают специфичные запросы к БД, которые могут затронуть другие записи, потому что мы не хотим очищать БД после каждого теста. 2. Тесты, которые юзают общую файловую систему, потому что мы не хотим поднимать для каждого теста контейнер. И т.д.
Блин, ну не дели на виды, дели на группы, в чем проблема? :D

 
Зачем уточнять причину, по которой тест нельзя гонять паралелльно?

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

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

 
Alexandr
19.05.2016
12:27:46
Затем, что каждую эту причину нужно документировать и объяснять новым людям =)

 
Юрий
19.05.2016
12:28:33
Затем, что каждую эту причину нужно документировать и объяснять новым людям =)
Это какое-то ненужное обобщение. Чего ты добьешься, выделив на каждую причину по группе?

 
будет у тебя 20 групп тестов вместо двух

 
а профит?

 
Alexandr
19.05.2016
12:28:57
Где я сказал, что я собираюсь выделять на каждую причину по группе?

Google
 
Vyatcheslav
19.05.2016
12:29:21
а еще можно in-memory БД использовать. Насчет ФС - имхо такие тесты целесообразно писать только для класса, работающего с ФС. Т.е. интеграционные тесты, работающие с ФС как-то хз… :)

 
Alexandr
19.05.2016
12:29:40
Моя мысль - не лучше ли вообще не иметь этих "причин"?

 
Юрий
19.05.2016
12:30:06
Моя мысль - не лучше ли вообще не иметь этих "причин"?
Очевидно, что если так можно, то нужно брать такой вариант.

 
Alexandr
19.05.2016
12:31:39
И еще, не совсем понятно, как меня спасет последовательное выполнение, если предыдущий тест сделал в БД какие-то изменения, которые следующий тест не ожидает

 
Юрий
19.05.2016
12:32:29
И еще, не совсем понятно, как меня спасет последовательное выполнение, если предыдущий тест сделал в БД какие-то изменения, которые следующий тест не ожидает
Тесты чистят за собой, об этом я писал выше

 
Alexandr
19.05.2016
12:32:49
Позже написали, что у них тесты не чистят за собой, а решается все уникальными id

 
Vyatcheslav
19.05.2016
12:32:58
короче, мы у себя пользуемся генерацией рандомных UUID. Тестов, работающих с БД не очень много - порядка 200, сущностей создается раз в 8-15 больше. У нас этот подход вполне хорошо работает )

 
и то, и другое

 
?Ivan
19.05.2016
12:33:27
Имхо тесты с БД не должны влиять друг на друга.

 
Alexandr
19.05.2016
12:34:21
И то, что в каждом тесте нужно писать, что именно почистить, это, ИМХО огромный риск человеческого фактора

 
Vyatcheslav
19.05.2016
12:34:53
не нужно. Фикстуры пишутся в виде Скала-классов, все разруливается рефлекшеном. Хотя можно и по-умнее сделать )

 
?Ivan
19.05.2016
12:36:00
Проблема мне кажется высосана из пальца

 
Alexandr
19.05.2016
12:36:23
Я так и не понял. Каждый тест должен удалять только то, что ему не нужно или ВСЕ фикстуры предыдущих тестов?))

 
Что имелось в виду под "каждый тест чистит за собой"?

 
?Ivan
19.05.2016
12:37:30
/stat@comstatbot

 
Combot
19.05.2016
12:37:30
combot.org/chat/-1001034178083

 
Vyatcheslav
19.05.2016
12:37:37
У каждого теста своя фикстура. Класс, работающий с фикстурами, чистит БД после успешного прохождения теста на основе фикстуры.

 
Юрий
19.05.2016
12:38:38
нифига я нафлудил по статистике

 
Vyatcheslav
19.05.2016
12:39:26
понятно, что тесты вполне могут генерить новые данные, но и это решается )

 
Alexandr
19.05.2016
12:39:51
» У каждого теста своя фикстура. » Класс, работающий с фикстурами, » чистит за собой после тестов. Короче, по сути, чистит БД.

Google
 
Alexandr
19.05.2016
12:41:10
» понятно, что тесты вполне могут генерить » новые данные, но и это решается ) Ага, введением еще одного правила)))

 
Viacheslav
19.05.2016
12:41:31
не слишком много кода получается в итоге? Предположим для теста сделать несколько инсёртов в несколько таблиц, потом в конце почистить все эти таблицы и плюс зааффекченные таблицы и ничего не забыть

 
Борис
19.05.2016
12:42:53
А для паралельных тестов еще убедится в невозможности сайд эфектов

 
Vyatcheslav
19.05.2016
12:43:56
Можно и без правила. Как-нибудь неявно решать вопрос ) Мы вообще на многое забили болт, поскольку у нас все тесты изолированные, id рандомные. Чистка нам по сути не важна (юзается как небольшой оптимизационный момент). Как будет необходимость - решим и это

 
Борис
19.05.2016
12:45:13
Вообщем или больше логики в тестах или долше поднимать окружение - основной трейдоф

 
Юрий
19.05.2016
12:45:54
я когда на джаве писал у нас инициализация и чистка была просто частью теста

 
и так много кто делал

 
и все считали это норм

 
не всё почистил - сам дурак

 
Vladimir
19.05.2016
12:46:21
Сдается мне, чистку хоть всех таблиц можно вынести нафиг в общий трейт, т.ч. написать ее надо будет 1 раз

 
Alexandr
19.05.2016
12:46:21
» Можно и без правила. Тогда каждый будет писать как хочет и начнется ад ?

 
» не всё почистил - сам дурак уууу

 
Юрий
19.05.2016
12:47:26
это же тесты, а не продакшен база

 
там можно на много забить

 
Борис
19.05.2016
12:51:23
В принципе да, делать полную чистку и запускать тесты последовательно не очень геморойный вариант

 
Slavik
19.05.2016
13:40:09
Справедливости ради, про 10^38 IDшников: там работает birthday paradox, чтобы огрести коллизию с вероятность 1/2 надо сгенерить примерно 10^20

 
Юрий
19.05.2016
13:41:29
http://stackoverflow.com/a/24876263

 
Slavik
19.05.2016
13:41:45
А в случае с long (64-bit) ID, где-то 10^10

 
Sergey Tolmachev
19.05.2016
13:42:52
а запускать каждый тест в своей транзакции не вариант?

 
Юрий
19.05.2016
13:43:17
А в случае с long (64-bit) ID, где-то 10^10
Откуда вы берете такие цифры?

Google
 
Dmitry
19.05.2016
13:43:44
генерируют

 
Slavik
19.05.2016
13:43:58
https://en.wikipedia.org/wiki/Birthday_attack

 
Dmitry
19.05.2016
13:44:02
у каждого в шкафу, есть такой генератор “умных" чисел

 
Юрий
19.05.2016
13:44:15
https://en.wikipedia.org/wiki/Birthday_attack
Only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. Or, to put it another way, the probability of one duplicate would be about 50% if every person on earth owned 600 million UUIDs.

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

 
Slavik
19.05.2016
13:44:28
64 бита, вероятность 1/2. 5.1 × 10^9

 
Юрий
19.05.2016
13:44:30
и она не дает такие цифры

 
Slavik
19.05.2016
13:44:41
прямо в табличке написано

 
ошибся в целых два раза, сорян =)

 
вообще - кол-во элементом хорошо оценивается квадратным корнем

 
Юрий
19.05.2016
13:45:46
В джаве UUID не хранится в лонге, он внутри себя использует несколько лонгов

 
так что это не корректное заявление

 
Slavik
19.05.2016
13:46:20
Да, в случае с UUID - это 10^20, как я писал

 
и это действительно похоже на "Only after generating 1 billion UUIDs every second for the next 100 years"

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

 
Pavel
19.05.2016
14:27:03
Прошу прощения за вторжение. Помогите, пожалуйста, найти сильного Senior Scala Developer разрабатывать с нами серверную часть www.Acotor.im Actor - это мессенджер под iOS, Android, веб и десктопы c открытым исходным кодом. Мы довольно популярны на гитхабе (https://github.com/actorapp/actor-platform, постоянно пилятся форки. Гарантируем интересные технические задачи, адекватную команду, уважительную зарплату на уровне. Офис находится в Петербурге, но возможна и удаленка. Писать можно мне на anton@actor.im Заранее благодарю.
Город не принято называть, или речь об удалёнке?

 
Anton
19.05.2016
14:29:14
Город не принято называть, или речь об удалёнке?
Принято, назван:"Офис находится в Петербурге, но возможна удаленка"

 
Alex
19.05.2016
17:21:42
как говорится, поставьте ?если дочитали сообщение до конца

 
Nikolay
19.05.2016
17:54:31
кто-то будет участвовать в новом цикле курсов по scala на coursera? там 4 курса начинаются в ближайшее время, собственно вот все они https://www.coursera.org/specializations/scala

 
Sergey Tolmachev
19.05.2016
18:06:07
их уже пару раз переносят

 
Nikolay
19.05.2016
18:06:20
уже вроде бы нет

 
Sergey Tolmachev
19.05.2016
18:06:51
я на 2 и 3 записывался, 1 уже проходил

Страница 7 из 1499