Программирование[11]

Просто по идее можно написать тест который будет запускать со слипом каждый помеченный как потенциально опасный метод в параллель к тестируемому. Должно дать какие гарантии и можно автоматизировать, не?

Arzanis написал 44 минуты назад:

Просто по идее можно написать тест который будет запускать со слипом каждый помеченный как потенциально опасный метод в параллель к тестируемому. Должно дать какие гарантии и можно автоматизировать, не?

Не совсем. Слипами и прочим ты тестируешь совокупность имплементации и кейсов которые ты не знаешь. А должен тестировать кейс которые ты знаешь.

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

Для этого достаточно и нужно мокать и абстрагировать. Тебе нужно придумать логику работы, и проверить то что ты эту логику заимплементил как ожидалось. Это и является предметом теста.

Тоесть в простейшем примере если у тебя есть метод exec_and_cache Тебе бы неплохо проверить что при вызове его происходит:

connection.lock

connection.exec

connection.unlock

cache.lock

cache.save

cache.unlock

И ни один другой метод не вызывается. Ты ведь продумал логику свою, логику в код транслировал, вот ее и проверяй. Проверяй что два лока в дедлок не могут принципиально встать. Вдруг ты подумал, но накодил cache.lock->connection.unlock?

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

Прописываю чтения документации о пусть будет gmock.

Впрочем я их понимаю, нахуй надо. Это все слишком сложно получается в итоге.

Grohuf написал 1 час назад:

По факту уже все сказано. Если ты не понял его доводы, то чем я могу помочь? У каждого есть свой предел.

Чтож, видимо мышления дуита это твой предел. Невысокий оказался.

Arzanis написал 1 час назад:

Просто по идее можно написать тест который будет запускать со слипом каждый помеченный как потенциально опасный метод в параллель к тестируемому. Должно дать какие гарантии и можно автоматизировать, не?

Ты не знаешь, где надо поставить слип, пока не видишь баг/крэш.

Пример хитровыебанного бага:

Class A : ThreadSafeRefcounted<A> {
// тут что-то
};

A::A() {
  PostTaskOnWorkerThread(this, &A::SomeMethod);
}
  
main() {
  auto a = MakeRefCounted<A>();
}

Класс A - с подсчетом ссылок. Когда он создается, он не выставляет счетчик ссылок в единицу, потому что всегда он присваивается умному указателю, который инкрементирует этот счетчик на единицу.

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

Чтобы воспроизвести этот крэш, надо поставить слип после PostTaskOnWorkerThread.

GoldRobot написал 26 минут назад:

Тоесть в простейшем примере если у тебя есть метод exec_and_cache Тебе бы неплохо проверить что при вызове его происходит:

connection.lock

connection.exec

connection.unlock

cache.lock

cache.save

cache.unlock

Наитупейший и бесполезнейший вариант тестов, которые у нас бывают пишут на "отъебись", чтобы не спрашивали "а почему нет тестов?"

Grohuf написал 46 минут назад:

Arzanis написал 1 час назад:

Просто по идее можно написать тест который будет запускать со слипом каждый помеченный как потенциально опасный метод в параллель к тестируемому. Должно дать какие гарантии и можно автоматизировать, не?

Ты не знаешь, где надо поставить слип, пока не видишь баг/крэш.

Пример хитровыебанного бага:

Class A : ThreadSafeRefcounted<A> {
// тут что-то
};

A::A() {
  PostTaskOnWorkerThread(this, &A::SomeMethod);
}
  
main() {
  auto a = MakeRefCounted<A>();
}

Класс A - с подсчетом ссылок. Когда он создается, он не выставляет счетчик ссылок в единицу, потому что всегда он присваивается умному указателю, который инкрементирует этот счетчик на единицу.

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

Чтобы воспроизвести этот крэш, надо поставить слип после PostTaskOnWorkerThread.

GoldRobot написал 56 минут назад:

Тоесть в простейшем примере если у тебя есть метод exec_and_cache Тебе бы неплохо проверить что при вызове его происходит:

connection.lock

connection.exec

connection.unlock

cache.lock

cache.save

cache.unlock

Наитупейший и бесполезнейший вариант тестов, которые у нас бывают пишут на "отъебись", чтобы не спрашивали "а почему нет тестов?"

 

дядь, ты не понял

Olololnet написал 3 минуты назад:

удаление объекта до завершения конструктора - интересная экзотика, в голову просто так не придёт

Есть много причин, почему нельзя писать сложный код в конструкторе и вместо этого использовать методы Init(). Хотелось бы настучать Страуструпу по ебалу за гениально спроектированный язык.

Ты провисшие ссылки то как собрался тестить? 

Еще рофл конечно такую хуйню в конструкторе писать. Конечно придется код написать так что бы он тестировался, а ты как думал?

Хотелось бы послушать как ты покрываешь тестами на протухсшие ссылки/указатели синхронный код. И в чем тут будет разница.

БТВ

Ты вообще какую-то аддовую хуйню написал. Если ты не передал туда владение, просто по this передал, то схуяли оно там должно декрементить и что-то удалять? Тоесть у тебя ThreadSafeRefcounted полагается что кто-то ИЗВНЕ зовет decrease_count или типа того?

Цитата

Когда умный указатель будет инкрементировать счетчик, он это будет делать у мертвого объекта (крэша скорее всего не будет в этом месте, но будет потом).

На момент вызова ThreadSafeRefcounted счетчик УЖЕ инкрементирован. Его конструктор уже отработал. unless ты отнаследующейся пометив public, и у тебя MakeRef ответственна за инкрементит.

Тогда это уже нихуя не умный указатель.

Не пишите такую хуету как грохуф, прошу вас и заклинаю, изайте шаред птры из стд.

GoldRobot написал 17 минут назад:

Не пишите такую хуету как грохуф, прошу вас и заклинаю, изайте шаред птры из стд.

Это писал не я, а чел из гугла. Я просто это фиксил (апстримил, офк).

Ты еще не знаешь проблем шаредптра...совсем плох. А такие умные указатели (в бусте они называются intrusive) используются далеко не только в Chromium. Например, в свое время в COMе было сделано именно так.

GoldRobot написал 20 минут назад:

Ты провисшие ссылки то как собрался тестить?

Я уже писал выше. Нагрузочное тестирование. Реализовать его мне хватило ума, когда у меня был 1 год стажа работы. В чем у тебя проблемы - не понимаю.

GoldRobot написал 22 минуты назад:

Конечно придется код написать так что бы он тестировался, а ты как думал?

Ты про свои гениальные тесты вида:

MyClass::MyFunc() {
  member_variable_ = 1;
}

MyTest() {
  MyClass tested_class;
  tested_class.MyFunc();
  assert(tested_class.member_variable_ == 1);
}

?

Да, очень полезные тесты. Согласен. Пишешь код в классе, а потом пишешь в тесте проверку, что все операции в функции действительно выполнились.

GoldRobot написал 25 минут назад:

БТВ

Ты вообще какую-то аддовую хуйню написал. Если ты не передал туда владение, просто по this передал, то схуяли оно там должно декрементить и что-то удалять? Тоесть у тебя ThreadSafeRefcounted полагается что кто-то ИЗВНЕ зовет decrease_count или типа того?

Я просто опустил шаблонную магию, чтобы было легче читать. Так-то понятно, что будет создан шаблоном код, который вызывает this->AddRef().

GoldRobot написал 26 минут назад:

На момент вызова ThreadSafeRefcounted счетчик УЖЕ инкрементирован. Его конструктор уже отработал. unless ты отнаследующейся пометив public, и у тебя MakeRef ответственна за инкрементит.

Тогда это уже нихуя не умный указатель.

Я вроде все расписал, а ты все равно не понял.

Grohuf написал 6 минут назад:

 

GoldRobot написал 33 минуты назад:

Конечно придется код написать так что бы он тестировался, а ты как думал?

Ты про свои гениальные тесты вида:

MyClass::MyFunc() {
  member_variable_ = 1;
}

MyTest() {
  MyClass tested_class;
  tested_class.MyFunc();
  assert(tested_class.member_variable_ == 1);
}

?

Да, очень полезные тесты. Согласен. Пишешь код в классе, а потом пишешь в тесте проверку, что все операции в функции действительно выполнились.

 

Судя по коду я попал в точку, ты вообще не понимаешь о чем говоришь  Флажки блять в классе. Ты ебанутый?

Узри же, МАГИЮ https://google.github.io/googletest/gmock_cook_book.html#OrderedCalls

Grohuf написал 9 минут назад:

Я просто опустил шаблонную магию, чтобы было легче читать. Так-то понятно, что будет создан шаблоном код, который вызывает this->AddRef().

Извне? AddRef чья обязанность позвать? Нету ThreadSafeRef/WeakThreadSafeRef?

Grohuf написал 13 минут назад:

Это писал не я, а чел из гугла. Я просто это фиксил (апстримил, офк).

Если ты такое дерьмище адское поддерживаешь, и допиливаешь. Без тестов и не умея тесты писать, мое тебе уважение брат.

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

Grohuf написал 14 минут назад:

Ты еще не знаешь проблем шаредптра...совсем плох.

Расскажи.

Grohuf написал 14 минут назад:

Я уже писал выше. Нагрузочное тестирование. Реализовать его мне хватило ума, когда у меня был 1 год стажа работы. В чем у тебя проблемы - не понимаю.

Нагрузочное тестирование не является проверкой на провисшие ссылки. Собственно как и проверки тредсейфа, о чем вы сами, вроде, доказали.

Еще идеи?

GoldRobot написал 1 минуту назад:

Судя по коду я попал в точку, ты вообще не понимаешь о чем говоришь  Флажки блять в классе. Ты ебанутый?

Узри же, МАГИЮ https://google.github.io/googletest/gmock_cook_book.html#OrderedCalls

Чел, я работаю над хромиумом, который делают в гугле. 

https://chromium.googlesource.com/chromium/src.git
Если у тебя сложности с поиском

GoldRobot написал 2 минуты назад:

Извне? AddRef чья обязанность позвать? Нету ThreadSafeRef/WeakThreadSafeRef?

Там все написано. Напряги извилины чуть-чуть.

GoldRobot написал 3 минуты назад:

Если ты такое дерьмище адское поддерживаешь, и допиливаешь. Без тестов и не умея тесты писать, мое тебе уважение брат.

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

Ты хоть в курсе, как написана библиотека std? Не просто так многие вещи из нее в гугле забанены.

GoldRobot написал 4 минуты назад:

Расскажи.

Использование std::make_shared является обязательным. Создал объект как-то не так - привет лишние тормоза. Никаких средств быть уверенным, что объект создается именно так. Если тебе неудобно - похуй, изворачивайся. Нельзя передавать сырой указатель, поэтому всегда лишние работы со счетчиком, которые в многопоточной среде должны быть атомарными.

Ебать вы тут насрали ходя вокруг да около. Сейчас вам батя все объяснит. 

Почему сложно тестировать многопоточный код:

Допустим у вас есть тред(бизнес-задача) А у которого есть состояния перед локом->лок->отдал лок и тред (бизнес-задача) Б с таким же состоянием (3 состояния)

Получается чтобы протестировать все поведение вам нужно в рамках теста сделать 3х3 (9 кейсов сочетаний состояний) и это только в статике. А есть ещё динамика, когда начинают в одном состоянии но другой прошел чуть быстрее а потом замедлился.

А когда число состояний увеличивается количество тест кейсов растет экспоненциально.

Опять же можно прибегнуть к виртуальному времени, как Vova упомянул, но это если у каждого из тредов есть возможность собственно то самое виртуальное время подсунуть. Есть точки где треды обращаются к Clock за временем.

Если же там чисто CPU не ожидающий, не блокирующийся код, то виртуальное время можно засунуть в жопу.

А когда в бизнес-логику напиханы точки входа для тестов. Типо давай сюда засунем Thread.sleep(clock.nanos(1)) и будем мокать клок в тестах))))0 то от такого кода хочется помыться 

P.S. Даже то же виртуальное время в разы лучше работает когда пишешь многопоточный код конкарент агностик вещами типо реактивщины/корутинщины

https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-test/kotlinx.coroutines.test/-delay-controller/advance-time-by.html

https://nexocode.com/blog/posts/fast-reactor-tests-with-virtual-time/

Моканье времени - вполне обычная практика. Хотя чаще надо мокать тики процессора, так как именно они в нормальном коде используются для пауз и измерения промежутков времени.

Index написал 20 минут назад:

от такого кода хочется помыться 

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

Чекнул cppreference. Оказывается при использовании std::make_shared weak_ptr не дает удалиться памяти, занимаемой всем объектом. Ну да, логично, там же одна аллокация. Короче, говно-говном.

Grohuf написал 22 минуты назад:

Использование std::make_shared является обязательным. Создал объект как-то не так - привет лишние тормоза. Никаких средств быть уверенным, что объект создается именно так. Если тебе неудобно - похуй, изворачивайся. Нельзя передавать сырой указатель, поэтому всегда лишние работы со счетчиком, которые в многопоточной среде должны быть атомарными.

Чел.

Это плата за безопасность. Ты сам себе злой буратино, который потом ебеться с тем что выше.

Если нет контеншена, то атомик довольно быстро работает.

Так же если классу НУЖНО разделяемое владение, что он ажно в себя вписывает, то он и должен быть, очевидно, обязательным.

Если ты пишешь говно по которому даже не ясно за что оно ответственно, то ССЗБ.

Grohuf написал 23 минуты назад:

Никаких средств быть уверенным, что объект создается именно так

Не отработают методы, если не шаредптр сделан.

Grohuf написал 25 минут назад:

Там все написано. Напряги извилины чуть-чуть.

Ну тоесть ты написал хуйню, объяснить которую даже не можешь.

Ясно.

Я удивлен что ты даже с gmock не знаком. Хотя казалось бы, не дуит, не дуит мы думали ты.

Grohuf написал 27 минут назад:

Ты хоть в курсе, как написана библиотека std? Не просто так многие вещи из нее в гугле забанены.

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

GoldRobot написал 1 минуту назад:

Если нет контеншена, то атомик довольно быстро работает.

Не надо пиздеть. Атомарный инкремент гораздо медленее работает обычного инкремента.

GoldRobot написал 3 минуты назад:

Ну тоесть ты написал хуйню, объяснить которую даже не можешь.

Ясно.

То есть ты сельский дурачок, который не понял довольно простой пост. Там написано "Когда он создается, он не выставляет счетчик ссылок в единицу, потому что всегда он присваивается умному указателю, который инкрементирует этот счетчик на единицу." Чего там может быть непонятно - я не представляю. Походу ты совсем тупой.

GoldRobot написал 3 минуты назад:

Я удивлен что ты даже с gmock не знаком. Хотя казалось бы, не дуит, не дуит мы думали ты.

Ого, пробиваешь очередное дно. Все тесты хромиума на нем написаны. Попробуй сделать логический вывод, знаком ли я с тем как они пишутся?

GoldRobot написал 4 минуты назад:

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

"Ту хуйню", которую ты не понял, что значит? Но на всякий случай лучше сжечь? Разумно.

Залил очень крутую тему на гитхаб залайкате чтобы в реки кинуло
думаю 1000+ лайков должно дать если запостят в каком нибудь телеграм канале.
https://github.com/ManulMap/malstring

#ХОЧУВРЕК

#ВРЕК

Grohuf написал 1 минуту назад:

Не надо пиздеть. Атомарный инкремент гораздо медленее работает обычного инкремента.

Хорошо, уговорил, ведь я этого и не пиздел.

Grohuf написал 1 минуту назад:

То есть ты сельский дурачок, который не понял довольно простой пост. Там написано "Когда он создается, он не выставляет счетчик ссылок в единицу, потому что всегда он присваивается умному указателю, который инкрементирует этот счетчик на единицу." Чего там может быть непонятно - я не представляю. Походу ты совсем тупой.

О, я легко объясни, чего не понятно.

Если 

Цитата

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

умный указатель инкрементирует при copy/assign/конструкторе счетчик, то он УЖЕ будет 1. На момент вызова PostTaskOnWorkerThread(this, &A::SomeMethod); его конструктор УЖЕ отработал. Ведь от этого умного указателя и отнаследовался класс. А внутри этой твоей PostTaskOnWorker создается, логично, новый умный указатель который подумает до 2.

Unless кто-то не умеет в мув семантику, не знает что такое RVO, и сделал буквально как ты написал. Что у тебя assign/copy constructor инкрементит, а просто конструктор нет, и потому можно создать объект с НУЛЕМ. Но тогда даже в синхронном однопоточном коде ты получишь абсолютно туже хуйню, что как-только умрет в PostTask последний референс, у тебя delete позовут.

Почему ты такой тупой? У тебя там какая-то лапша из дерьма написана, и я хуй просышь что за лапша. Объясни нормально.

Грохув кто-то прочитал гугловые стандарты, даже абсеил, нихуя не понял, но решил что слишком умный. std::shared_ptr специально сделали только с атомик версией. Потому что нирли нихуя не стоит, если ты не используешь многопоток, и чтобы не усложнять жизнь.

Если у тебя есть какой-то кровь из носу нужный заоптимизировать кейс, то возьми shared_ptr имплементацию, и вырежи к хуям атомики. А лучше возьми имплементацию boost::local_shared_ptr (хуй ты об этом знаешь я подозреваю).

А std::enable_shared_from_this, если ты блять не подумал, сделан именно так как сделан что бы не ебаться с кодом из твоего примера. Именно потому там внутри weak_ptr всегда создается. Именно потому из объекта, который создается вголую без shared_ptr, ты не можешь сделать shared_ptr, в отличии от твоего примера.

И даже если ты сделаешь

class A: public std::enable_shared_from_this
{}
auto aptr = new A{};
std::shared_ptr<A>(aptr)

Оно всеравно корректно отработает. Представь, блять, себе, на само деле не обязательно make_shared звать на самом деле, можно и ручками. Достаточно звать shared_from_this() когда уже будет ясно кто должен чистить объект, будет овнер, собственно появится шаред птр. А даже если не сделать этого, выкинется просто эксепшен. Умно, не правда ли?

За тебя уже подумали. За тебя уже сделали. Сделали как надо. Бери и пользуй. Либо хотя бы перенимай опыт.

Из-за таких кодеров индексы ловят инфаркт, а дуиты смеются с плюсов застряв в С98. Не делайте так.

Я конечн лайкнул, но как только лайкнул пришло письмо:

Grohuf написал 1 час назад:

Ого, пробиваешь очередное дно. Все тесты хромиума на нем написаны. Попробуй сделать логический вывод, знаком ли я с тем как они пишутся?

Cмотря на то как ты пишешь тесты:

Grohuf написал 2 часа назад:

Ты про свои гениальные тесты вида:

MyClass::MyFunc() {
  member_variable_ = 1;
}

MyTest() {
  MyClass tested_class;
  tested_class.MyFunc();
  assert(tested_class.member_variable_ == 1);
}

?

Да, очень полезные тесты. Согласен. Пишешь код в классе, а потом пишешь в тесте проверку, что все операции в функции действительно выполнились.

Делаю логичный вывод что нет, нихуя не знаком.

GoldRobot написал 8 минут назад:

умный указатель инкрементирует при copy/assign/конструкторе счетчик, то он УЖЕ будет 1. На момент вызова PostTaskOnWorkerThread(this, &A::SomeMethod); его конструктор УЖЕ отработал. Ведь от этого умного указателя и отнаследовался класс. А внутри этой твоей PostTaskOnWorker создается, логично, новый умный указатель который подумает до 2.

Класс A не является умным указателем. Ахаха.