Это всё пустые слова, Евгений. Ну ничего не значат.

пока от тебя ничего значащего не услышал

С Идрис, думаю, всё ещё имеются некоторые проблемы с производительностью? Энивей, это может возыметь эффект, если начнут применять опыт идриса на повседневные задачи.)

тоже вопрос размера комьюнити в принципе

В какой программе лучше всего писать код на C++

теория unit-test говорит мне "развяжи зависимость модуля", они забывают добавить, как я должен развязать зависимость модуля, который требует данных операционной системы

Идея же простая. Мы делаем трактор. Он состоит из корпуса, двигателя и гусениц. И бака с горючим. Чтобы всё работало вместе, НЕОБХОДИМОЕ условие, чтобы всё работало по отдельности. Работало — значит, выполняло свою функцию. Бак с горючим не должет течь в ненужных местах, а должен из топливопровода. Берём бак, заливаем что-то ... Смотрим . Из бензопровода течёт? Течёт, ок. Из других мест течёт, ? Нет. ОК, С баком всё в порядкп.

В какой программе лучше всего писать код на C++

@supapro

теория unit-test говорит мне "развяжи зависимость модуля", они забывают добавить, как я должен развязать зависимость модуля, который требует данных операционной системы

mock

Идея же простая. Мы делаем трактор. Он состоит из корпуса, двигателя и гусениц. И бака с горючим. Чтобы всё работало вместе, НЕОБХОДИМОЕ условие, чтобы всё работало по отдельности. Работало — значит, выполняло свою функцию. Бак с горючим не должет течь в ненужных местах, а должен из топливопровода. Берём бак, заливаем что-то ... Смотрим . Из бензопровода течёт? Течёт, ок. Из других мест течёт, ? Нет. ОК, С баком всё в порядкп.

Глядим далее. Двигатель должен крутиться, должен заводится, набирать обороты с опред. параметрами, выдавать нужную мощность. .... Берём и смортим. Вот тут кстати нужен СТЕНД (mocking)

В какой программе лучше всего писать код на C++

@supapro (vim, очевидно)

Глядим далее. Двигатель должен крутиться, должен заводится, набирать обороты с опред. параметрами, выдавать нужную мощность. .... Берём и смортим. Вот тут кстати нужен СТЕНД (mocking)

#explain_like_i_am_five #unit_testing

#explain_like_i_am_five #unit_testing

Ну а чего делать-то если явно человек не понимает...

теория unit-test говорит мне "развяжи зависимость модуля", они забывают добавить, как я должен развязать зависимость модуля, который требует данных операционной системы

то ФП над которым те смеешься как раз дает идеальные юнит-тестируемые штуки - функции без сайд эффектов

Глядим далее. Двигатель должен крутиться, должен заводится, набирать обороты с опред. параметрами, выдавать нужную мощность. .... Берём и смортим. Вот тут кстати нужен СТЕНД (mocking)

А ВОТ КОГДА МЫ ВСЕ части по отдельности проверим, и соберём весь трактор, НАДО ЕГО ТЕСТИРОВАТЬ ЦЕЛИКОМ, Это НЕ UNit-tests. Это уже функциональные тесты.

то ФП над которым те смеешься как раз дает идеальные юнит-тестируемые штуки - функции без сайд эффектов

Ага, и ещё распараллеливаемые на любом этапе выполнения.

Глядим далее. Двигатель должен крутиться, должен заводится, набирать обороты с опред. параметрами, выдавать нужную мощность. .... Берём и смортим. Вот тут кстати нужен СТЕНД (mocking)

Я понимаю логическую компоненту unit-test, я не понимаю пользу от них. Смотри, по сути речь идет о фасаде, отгораживающем C++ код от winapi и дающем адекватную C++ модель. Ты мне говоришь - поставь стенд вместо системы и тестируй. Вот поверь, код, который проверен человеком по протоколу тестирования на этом фасаде будет проходить ВСЕ тесты, которые основаны на ДОКУМЕНТИРОВАННОМ поведении операционной системы. Написание этого стенда и последующее его использование для тестов займет время, в ТОЧНОСТИ равное написанию всего фасада, поскольку стенд В ТОЧНОСТИ основан на ТОЙ ЖЕ САМОЙ документации, что и фасад

Я понимаю логическую компоненту unit-test, я не понимаю пользу от них. Смотри, по сути речь идет о фасаде, отгораживающем C++ код от winapi и дающем адекватную C++ модель. Ты мне говоришь - поставь стенд вместо системы и тестируй. Вот поверь, код, который проверен человеком по протоколу тестирования на этом фасаде будет проходить ВСЕ тесты, которые основаны на ДОКУМЕНТИРОВАННОМ поведении операционной системы. Написание этого стенда и последующее его использование для тестов займет время, в ТОЧНОСТИ равное написанию всего фасада, поскольку стенд В ТОЧНОСТИ основан на ТОЙ ЖЕ САМОЙ документации, что и фасад

Ручное тестирование? Ох

Ручное тестирование в два раза дешевле разработки кода

Оно же не даёт понимания причины выявляемых проблем.

Я понимаю логическую компоненту unit-test, я не понимаю пользу от них. Смотри, по сути речь идет о фасаде, отгораживающем C++ код от winapi и дающем адекватную C++ модель. Ты мне говоришь - поставь стенд вместо системы и тестируй. Вот поверь, код, который проверен человеком по протоколу тестирования на этом фасаде будет проходить ВСЕ тесты, которые основаны на ДОКУМЕНТИРОВАННОМ поведении операционной системы. Написание этого стенда и последующее его использование для тестов займет время, в ТОЧНОСТИ равное написанию всего фасада, поскольку стенд В ТОЧНОСТИ основан на ТОЙ ЖЕ САМОЙ документации, что и фасад

нде

Тебе придётся как-то воспроизводить ситуацию, дебажить...

Это трата времени разаботки.

@berkus вот что тебе не нравится? ты хочешь сказать, что стенд на самом деле не повторит логическую модель фасада с другой стороны?

А можно было это потратить на написание теста и проще находить проблемы.

Тебе придётся как-то воспроизводить ситуацию, дебажить...

Мне и так придется, вряд ли найденная ошибка СООТВЕТСТВУЕТ документации входа со стороны ОС

Которому СООТВЕТСТВУЕТ стенд

@berkus вот что тебе не нравится? ты хочешь сказать, что стенд на самом деле не повторит логическую модель фасада с другой стороны?

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

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

тестировать при _каждом изменении кода_

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

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

примерно... никогда?

ну и юнит тестами ты тестируешь не винапи

мое мде было про это

в этом и проблема

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

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

но 90% ошибок будет вызвано моим непониманием winapi

не исключая варианта что ты хочешь тестировать вообще не то что надо тестировать

юнит-тесты станут не нужны когда Idris захватит мир

Тоталити чекер уже починили? ;D

Я понимаю логическую компоненту unit-test, я не понимаю пользу от них. Смотри, по сути речь идет о фасаде, отгораживающем C++ код от winapi и дающем адекватную C++ модель. Ты мне говоришь - поставь стенд вместо системы и тестируй. Вот поверь, код, который проверен человеком по протоколу тестирования на этом фасаде будет проходить ВСЕ тесты, которые основаны на ДОКУМЕНТИРОВАННОМ поведении операционной системы. Написание этого стенда и последующее его использование для тестов займет время, в ТОЧНОСТИ равное написанию всего фасада, поскольку стенд В ТОЧНОСТИ основан на ТОЙ ЖЕ САМОЙ документации, что и фасад

Ну, Я как мог, разъяснил... Более детально не смогу...

в windows vista исправляют ошибку windows xp в comctrl, что поведение одной из функций не соответствует документации - и все ложится, но стенд соответствует не windows vista

Ну, Я как мог, разъяснил... Более детально не смогу...

я примерно понимаю теорию, я лишь не понимаю, как её использовать на практике от слова совсем

то ФП над которым те смеешься как раз дает идеальные юнит-тестируемые штуки - функции без сайд эффектов

кстати, я не смеюсь над ФП, если ты обратил внимание я сторонник максимальной compile time строгости

я примерно понимаю теорию, я лишь не понимаю, как её использовать на практике от слова совсем

Мне вообще кажется, что нормально протестировать систему целиком можно только когда она изначально написана по принципу "write test first, write code later" А если есть готовая связная система, то ее проще будет переписать "правильно" чем выгрызать тестируемые кусочки и писать юниттесты под них...

Всем хаюшки, Кому интересны корутины, посмотрите на https://stdcpp.ru/proposals/9e87c99d-226e-47e8-b88b-231b60e68989 Если есть идеи, предложения, замечания - с радостью выслушаю

привет) тут с шарповыми yield'ами недавно разобрался. Форнёвер говорит, что в плюсах хотят аналогичную функциональность занести

И зря.

Мне вообще кажется, что нормально протестировать систему целиком можно только когда она изначально написана по принципу "write test first, write code later" А если есть готовая связная система, то ее проще будет переписать "правильно" чем выгрызать тестируемые кусочки и писать юниттесты под них...

Моя проблема в том, что даже если я начну писать с тестов, я НЕ ПОНИМАЮ, что мне писать

Async-await сделает невозможным использовать легаси в асинхронном контексте, потому что возвращаемые значения надо либо разворачивать, либо заражать future<>

И зря.

ща посмотрел пример в stdcpp.ru, там они возвращают футуру. а в шарпе возрващают итератор (IEnumerator)

Лучше бы breakable-context-ы завезли.

По-моему это очень сильный шаг с awaitable значением не туда.

Я уже несколько лет работаю на плюсах с корутинами другого типа и представляю их удобства.

Тем более что если хочется, то одно через другое выражается.

Моя проблема в том, что даже если я начну писать с тестов, я НЕ ПОНИМАЮ, что мне писать

Я тож не понимал, как мне писать тесты к задачке "рисовать в куте симуляцию притягивающихся и отталкивающихся шариков" Долго думал, потом пришел к "пусть будет система с шариками отдельным объектом, буду проверять что через 50 циклов симуляции, один шарик - не движется, а два - движутся навстречу друг другу", и завертелось

Это функциональное, а не unit тестирование.

Чому нет?

Ну я уже пытался это втолковать.

Моя проблема в том, что даже если я начну писать с тестов, я НЕ ПОНИМАЮ, что мне писать

Константин, чтобы тебя утешить, я должен сказать, что не только ты один этого не понимаешь. Многие не поинимают. И многои не понимают, где заканчиваются юнит-тесты, и идут уже функциональные. Так и живём...

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

Нет

Не так.

Юнит не об этом.

Ну, перед тем как тестировать симуляции, я писал отдельные тесты аля "если шарик сдвинуть на Х, он 1) сдвинется 2) на Х а не на чтонибудь еще"

Да нет, именно об этом. Главное назначение юнит-тестов — проверить, что после изменения кода, ничего не сломалось в тех местах, где код не менялся.

Ты хочешь построить дом. ТЕбе нужны крепкие кирпичи и балки. Если хоть одна балка ломается — у тебя весь дом упадёт. Тебе надо СНАЧАЛА проверить каждый кирпич и балку, ПОТОМ собирать дом. Это НЕ ДАСТ гарантии, что Дом целиком будет стоять. Но ЕСЛИ балка или кирпич будут ломанными, дом ТОЧНО УПАДЁТ.

гарантии, что дом будет стоять дают интеграцинные тесты ?

А white или black box для юнит-тесте — НЕ ВАЖНО.

гарантии, что дом будет стоять дают интеграцинные тесты ?

Правильно.

ERROR: S client not available

Я тож не понимал, как мне писать тесты к задачке "рисовать в куте симуляцию притягивающихся и отталкивающихся шариков" Долго думал, потом пришел к "пусть будет система с шариками отдельным объектом, буду проверять что через 50 циклов симуляции, один шарик - не движется, а два - движутся навстречу друг другу", и завертелось

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

про тесты рендереров вообще тема очень туманная

Да нет, именно об этом. Главное назначение юнит-тестов — проверить, что после изменения кода, ничего не сломалось в тех местах, где код не менялся.

Нет. Это — регрессионные тесты. ЭТо классификация тестов по назначению. Регрессионными могут быть любые тесты, и Unit, и FUnctinal и Intergarion И любые.

Ты хочешь построить дом. ТЕбе нужны крепкие кирпичи и балки. Если хоть одна балка ломается — у тебя весь дом упадёт. Тебе надо СНАЧАЛА проверить каждый кирпич и балку, ПОТОМ собирать дом. Это НЕ ДАСТ гарантии, что Дом целиком будет стоять. Но ЕСЛИ балка или кирпич будут ломанными, дом ТОЧНО УПАДЁТ.

Вот только если у меня не работает балка под названием корневой комбобокс, у меня дом сломался и я это вижу

про тесты рендереров вообще тема очень туманная

авторы цсса хотели тестить корректность реализации цсс-правил через сравнение скринов

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

А это можно вообще не тестировать.

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

Я хотел рисовать шарики в буфер и проверять что нужная область закрасилась, но время поджимало)

Вот только если у меня не работает балка под названием корневой комбобокс, у меня дом сломался и я это вижу

Ты видишь, что дом сломался. А ПОЧЕМУ ты НЕ ВИДИШЬ.

Юнит-тесты и являются по назначению регрессионными. Из всех регрессионых — они самые детальные. И по этой же причине — они обычно whitebox, и пишутся программистом, и дёргают не за публичные интерфейсы. Я здесь исключительно о практике говорю.

Я хотел рисовать шарики в буфер и проверять что нужная область закрасилась, но время поджимало)

И это просто верх бесполезности по сути; если поломана корневая функциональность, это выясняется мгновенно

Нет. Это — регрессионные тесты. ЭТо классификация тестов по назначению. Регрессионными могут быть любые тесты, и Unit, и FUnctinal и Intergarion И любые.

А какие фреймворки есть в цпп под функциональные, системные и регресионные? Теория в универе это замечательно, но инструмента мне дать так и не смогли :/

Всё в кучу. Регрессионность ортогональна функциональности.

Gtest/gmock. Но это скорее для unit тестов. Для интеграционных или функциональных по понятным причинам какой-то универсальный фреймворк написать сложно.

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

Очень часто там специфика прет, поэтому универсальный фреймворк не прокатит

Gtest/gmock. Но это скорее для unit тестов. Для интеграционных или функциональных по понятным причинам какой-то универсальный фреймворк написать сложно.

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

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

забудьте, чему вас учили в университетах (с)

забудьте, чему вас учили в университетах (с)

Видимо, у меня был хороший университет — никогда такой глупости не слышал ни от кого.

забудьте, чему вас учили в университетах (с)

бесит когда так грят, какоето дешовое оскарбление

бесит когда так грят, какоето дешовое оскарбление

Окай. You were right, John. It's not like in the books. (с)

Окай. You were right, John. It's not like in the books. (с)

тут как то менее резко

Чуваки, плюсоните плс https://gitlab.kitware.com/cmake/cmake/issues/16708#note_326478

тут как то менее резко

Это предсмертная цитата парниши из Constantine

Это предсмертная цитата парниши из Constantine

кстати Constantine это чьто?

кстати Constantine это чьто?

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

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

оклан

кстати Constantine это чьто?

комикс

Видимо, у меня был хороший университет — никогда такой глупости не слышал ни от кого.

Университет не учит и не может учить практическим аспектам

Я с трудом представляю доктора наук, который на первой лекции по прикладному ПО скажет "сейчас я вас научу правильно ставить костыли"

Но это уже какой-то полный офтоп предлагаю /thread

А вот как в той же Qt написаны unit-test надо посмотреть

https://miyuki.github.io/2017/10/04/gcc-archaeology-1.html