Юнит-тесты это миф
юнит-тесты станут не нужны когда Idris захватит мир
доня.
Constantine
10000 строк кода в одной функции?
тогда ты что-то делаешь не так, лол
Нет, 10000 строк между начальными данными и фактическим результатом. Итоговая функция вычисляет сцену для рендерера на основании входных параметров, полученных от окон
🦥Alex Fails
ну если ты каждый день не можешь жить без этих прекрасных функций - повод топить за VS17
в вижл ассисте более-менее сделали эт
Constantine
Ну в смысли, ты разве не разбиваешь код на части?
Нет, в смысле, если я могу код проверить вычиткой или речь идет о проверке функции строк в 100
Berkus
А веб-сервер на haskell.org на хаскеле?
у меня вики крутится на хаскеле, умеет mediawiki markup и довольно адекватна
Berkus
на пехапе
Constantine
Ну тогда расскажи мне, какие юнит-тесты я должен написать, скажем, для модуля преобразования документа из RTF в HTML
Крылатый
Ну тогда расскажи мне, какие юнит-тесты я должен написать, скажем, для модуля преобразования документа из RTF в HTML
Ну тут тебе не только юнит-тесты нужны)
Constantine
Ну тут тебе не только юнит-тесты нужны)
Скажи мне, какие unit-тесты я вообще могу использовать
Berkus
тут 4 слоя тестов понадобится пожалуй
Крылатый
На каждую функцию же!
Крылатый
// серьёно, ну блин...
Berkus
ну не умеют люди в тестирование не кипятись)
Berkus
жирные не компилящиеся системы умеют писать, а тестировать их - для лохов
Constantine
я просто не верю в unit-тесты от слова совсем, кроме 5% задач
Berkus
я просто не верю в unit-тесты от слова совсем, кроме 5% задач
ну вы не тестируете, то, что понаписали, правильно? заказчик если что напишет "вот тут мол не работае"
Constantine
ну вы не тестируете, то, что понаписали, правильно? заказчик если что напишет "вот тут мол не работае"
тестируем, с горем пополам, разумеется; код обмазан самопроверками, которые составляют процентов 10 кодовой базы минимум
Крылатый
я просто не верю в unit-тесты от слова совсем, кроме 5% задач
Тут не вопрос веры. Тесты вполне хороший показатель стабильности работы в каких-то заданных рамках.
Berkus
самопроверки это ассерты или таки юнит тесты?
Constantine
ассерты
Berkus
одно дело инварианты в рантайме и другое дело ловить фаззинг какой-нибудь ДО релиза
Berkus
и то и другое, очевидно, необходимо
Constantine
проблема, что все модули, которые любят отказывать, могут быть протестированы только человеческой оценкой работоспособности
🐙 Antony
Всем хаюшки,
Кому интересны корутины, посмотрите на https://stdcpp.ru/proposals/9e87c99d-226e-47e8-b88b-231b60e68989
Если есть идеи, предложения, замечания - с радостью выслушаю
Constantine
одно дело инварианты в рантайме и другое дело ловить фаззинг какой-нибудь ДО релиза
теория unit-test говорит мне "развяжи зависимость модуля", они забывают добавить, как я должен развязать зависимость модуля, который требует данных операционной системы
Constantine
например, как я должен развязать зависимость между winapi сообщениями, которые триггерит операционная система, и внешней мордой комбобокса для C++ кода
Evgenii
запруфь обратное
Evgenii
пока от тебя ничего значащего не услышал
Evgenii
Dead
В какой программе лучше всего писать код на C++
Berkus
#explain_like_i_am_five #unit_testing
Berkus
теория unit-test говорит мне "развяжи зависимость модуля", они забывают добавить, как я должен развязать зависимость модуля, который требует данных операционной системы
то ФП над которым те смеешься как раз дает идеальные юнит-тестируемые штуки - функции без сайд эффектов
Constantine
Я понимаю логическую компоненту unit-test, я не понимаю пользу от них. Смотри, по сути речь идет о фасаде, отгораживающем C++ код от winapi и дающем адекватную C++ модель. Ты мне говоришь - поставь стенд вместо системы и тестируй. Вот поверь, код, который проверен человеком по протоколу тестирования на этом фасаде будет проходить ВСЕ тесты, которые основаны на ДОКУМЕНТИРОВАННОМ поведении операционной системы. Написание этого стенда и последующее его использование для тестов займет время, в ТОЧНОСТИ равное написанию всего фасада, поскольку стенд В ТОЧНОСТИ основан на ТОЙ ЖЕ САМОЙ документации, что и фасад
Constantine
Ручное тестирование в два раза дешевле разработки кода
Крылатый
Оно же не даёт понимания причины выявляемых проблем.
Крылатый
Тебе придётся как-то воспроизводить ситуацию, дебажить...
Крылатый
Это трата времени разаботки.
Constantine
@berkus вот что тебе не нравится? ты хочешь сказать, что стенд на самом деле не повторит логическую модель фасада с другой стороны?
Крылатый
А можно было это потратить на написание теста и проще находить проблемы.
Constantine
Тебе придётся как-то воспроизводить ситуацию, дебажить...
Мне и так придется, вряд ли найденная ошибка СООТВЕТСТВУЕТ документации входа со стороны ОС
Constantine
Которому СООТВЕТСТВУЕТ стенд
Evgenii
@berkus вот что тебе не нравится? ты хочешь сказать, что стенд на самом деле не повторит логическую модель фасада с другой стороны?
дело в том что тесты пишешь один раз, а вручную каждый раз тестировать
Constantine
дело в том что тесты пишешь один раз, а вручную каждый раз тестировать
тестировать при _каждом изменении кода_
Constantine
как ты думаешь, насколько часто меняется реализация фасадов операционной системы?
Berkus
как ты думаешь, насколько часто меняется реализация фасадов операционной системы?
примерно... никогда?
Berkus
ну и юнит тестами ты тестируешь не винапи
Berkus
мое мде было про это
Constantine
в этом и проблема
Berkus
ты тестируешь адекватность поведения своей прослойки
Constantine
ты тестируешь адекватность поведения своей прослойки
но 90% ошибок будет вызвано моим непониманием winapi
Berkus
не исключая варианта что ты хочешь тестировать вообще не то что надо тестировать
Constantine
в windows vista исправляют ошибку windows xp в comctrl, что поведение одной из функций не соответствует документации - и все ложится, но стенд соответствует не windows vista
Constantine
я примерно понимаю теорию, я лишь не понимаю, как её использовать на практике от слова совсем
Berkus
Constantine
то ФП над которым те смеешься как раз дает идеальные юнит-тестируемые штуки - функции без сайд эффектов
кстати, я не смеюсь над ФП, если ты обратил внимание я сторонник максимальной compile time строгости
Igor
я примерно понимаю теорию, я лишь не понимаю, как её использовать на практике от слова совсем
Мне вообще кажется, что нормально протестировать систему целиком можно только когда она изначально написана по принципу "write test first, write code later"
А если есть готовая связная система, то ее проще будет переписать "правильно" чем выгрызать тестируемые кусочки и писать юниттесты под них...
🦥Alex Fails
Всем хаюшки,
Кому интересны корутины, посмотрите на https://stdcpp.ru/proposals/9e87c99d-226e-47e8-b88b-231b60e68989
Если есть идеи, предложения, замечания - с радостью выслушаю
привет) тут с шарповыми yield'ами недавно разобрался. Форнёвер говорит, что в плюсах хотят аналогичную функциональность занести
Andrei
И зря.
Constantine
Мне вообще кажется, что нормально протестировать систему целиком можно только когда она изначально написана по принципу "write test first, write code later"
А если есть готовая связная система, то ее проще будет переписать "правильно" чем выгрызать тестируемые кусочки и писать юниттесты под них...
Моя проблема в том, что даже если я начну писать с тестов, я НЕ ПОНИМАЮ, что мне писать
Andrei
Async-await сделает невозможным использовать легаси в асинхронном контексте, потому что возвращаемые значения надо либо разворачивать, либо заражать future<>
🦥Alex Fails
И зря.
ща посмотрел пример в stdcpp.ru, там они возвращают футуру. а в шарпе возрващают итератор (IEnumerator)
Andrei
Лучше бы breakable-context-ы завезли.
Andrei
По-моему это очень сильный шаг с awaitable значением не туда.
Andrei
Я уже несколько лет работаю на плюсах с корутинами другого типа и представляю их удобства.
Andrei
Тем более что если хочется, то одно через другое выражается.
Igor
Моя проблема в том, что даже если я начну писать с тестов, я НЕ ПОНИМАЮ, что мне писать
Я тож не понимал, как мне писать тесты к задачке "рисовать в куте симуляцию притягивающихся и отталкивающихся шариков"
Долго думал, потом пришел к "пусть будет система с шариками отдельным объектом, буду проверять что через 50 циклов симуляции, один шарик - не движется, а два - движутся навстречу друг другу", и завертелось
Andrei
Это функциональное, а не unit тестирование.
Igor
Чому нет?
Andrei
Unit тестирование, это скорее вайтбокс тестирование, когда ты знаешь код, и юнит-тесты как правило тестируют оооочень маленький кусочек. В идеальном мире, на каждый if в коде должно быть два юнит-теста, которые создают условия для попадания в разные бранчи и проверяют, что код в них попал.
Igor
Ну, перед тем как тестировать симуляции, я писал отдельные тесты аля "если шарик сдвинуть на Х, он 1) сдвинется 2) на Х а не на чтонибудь еще"
Andrei
Да нет, именно об этом. Главное назначение юнит-тестов — проверить, что после изменения кода, ничего не сломалось в тех местах, где код не менялся.
🦥Alex Fails
гарантии, что дом будет стоять дают интеграцинные тесты 😂