Фил Ранжин
я так это вижу - тесты прибавляют защищённости, но пожирают бюджет. И субъективно - оно того не стоит
Karen
Есть у кого хорошая аргументация против юнит тестов как таковых?
смотря какой продукт, естественно. Если даже DDD не применимо, то я бы отказался как от лишней потери времени
Romɑn
пересмотри его, он хорошо рассказывает же
Фил Ранжин
ссылку?
Karen
ко всему прочему, такой код ковередж сложнодостижим
Karen
(видел проекты с пустыми тестами абы вызывало что и не падало), там как раз достигали 90%
Фил Ранжин
ну блядь, у нас ещё нет возможности использовать штуки вроде ms.fakes
Фил Ранжин
так что 90% уже не получится
Vladislav
по мне логично важные вещи чекать
Vladislav
кусками
Vladislav
но не 100%
Фил Ранжин
ну вот я 10 тонн строк закомитил
Фил Ранжин
проверок гет сетов
Vladislav
топ
Фил Ранжин
и понял, что я долбаёб
Vladislav
выполнил план на заводе
Vladislav
напечатал строк кода)
Фил Ранжин
хехе
Фил Ранжин
по мне логично важные вещи чекать
можешь дать кейс, где юнит тест действительно очень нужен?
Фил Ранжин
прям на пальцах, вот есть метод, делает то-то, тестим так-то
Фил Ранжин
томушт то-то
Фил Ранжин
это слишком абстрактно
Karen
ну, есть у нас модуль, который считает выплату долга для бизнеса на следующие n-лет
Vladislav
можешь дать кейс, где юнит тест действительно очень нужен?
ну я вот я вчера портировал кусок из кишок винформс, сделал я это с костылями потому что мне надо было все сделать так, чтобы не было зависимости от System.Windows.Forms и System.Drawing. в итоге я написал тестов чтобы проверить что оно читает данные как и оригинал https://github.com/Liminiens/resx-standard/blob/master/tests/Resx.Tests/ResXDataNode_Tests.cs
Vladislav
иначе там только с крестом сидеть
Vladislav
так видно сразу если отъебнет где-то
Romɑn
ссылку?
https://www.youtube.com/results?search_query=Anton+Moldovan
Karen
по месяцам, математики не много, но часто он используется в разных частях апихи, пару раз чуть не сломали рабочий функционал фиксом бага. (Сложно подробнее описать, если варишься с этим часто)
Romɑn
блин
Romɑn
что за фигня?
Romɑn
Seq.unzip нет что ли?
Pavel
Seq.unzip нет что ли?
List.unzip << Seq.toList
Фил Ранжин
на f# проект?
ох если бы
Pavel
скажи что 90% можно обеспечить только используя measures а они только в f#. пусть выбирают
Roman
Есть у кого хорошая аргументация против юнит тестов как таковых?
Для того, чтобы они приносили реальную пользу, в них должно быть кода больше, чем в самом приложении. И времени они пожирают соответственно. И поддерживать их заебно. И если стоит цель покрытия 90% — то это выльется через 2-3 месяца в то, что тесты будут писаться на отъебись, лишь бы их актуализировать приходилось пореже
Roman
И фундаментальная проблема в том, что тест пишет сам разработчик, который писал свой код, и он склонен писать тесты с учетом своей имплементации. А если заставлять писать тесты на код других членов команды, это будет занимать еще больше времени, пушто смена контекста и вообще в рафинированном ООП с иок фреймворками юнит тесты вынуждены нарушать инкапсуляцию
Hog
Я дико извиняюсь... только мельком увидел с утра - кто-то кого-то просил забанить... тут же всё обновилось и исчезло... чо было-то? :)
Bonart
Тогда они дают профит
Bonart
А вот процент покрытия как цель сам по себе нафиг не нужен
Bonart
Еще один источник профита - цена косяка, детектируемого тестами.
Dmitry
"юнит тесты вынуждены нарушать инкапсуляцию" - а вот если их писать не в отдельном модуле, а прямо с боевым кодом (вроде в Расте так делают) то из тестов все кишочки видны
Shub
но это в теории. на практике любой PR состоит из изменений в коде и соответствующих изменений в тестах в пропорции 1:1
Bonart
но это в теории. на практике любой PR состоит из изменений в коде и соответствующих изменений в тестах в пропорции 1:1
Нет, конечно. Рефакторинги в тестах меняют на порядки меньше, чем в остальном коде.
Shub
Юнит-тесты не должны нарушать инкапсуляцию. Иначе они просто делают код более хрупким без всяких плюшек
юнит-тесты в принципе не могут ничего нарушать. нарушает обычно разработчик, который не может написать тестируемый код
Shub
Нет, конечно. Рефакторинги в тестах меняют на порядки меньше, чем в остальном коде.
если в твоей практике это так, то тебе очень повезло и я тебе по-доброму завидую
Bonart
если в твоей практике это так, то тебе очень повезло и я тебе по-доброму завидую
Тесты которые надо менять на каждое изменение в коде обычно выпиливаются как бесполезные
Shub
в теории. да
Bonart
в теории. да
Ну я на практике так делаю.
Shub
вы нанимаете?
Bonart
вы нанимаете?
Я работаю :) Выпиливаю своими руками
Shub
в смысле, у вас вакансии есть? я бы задумался
Hog
Рано или поздно функциональное программирование ворвётся в ваш дом (с) АХ.
Hog
гыыыы :)
Romɑn
List.unzip << Seq.toList
Но ведь в 4 фш говорили что нет таких ф-ций которые бы были только в Листе или в Массиве или в последовательности...
Klei
Но ведь в 4 фш говорили что нет таких ф-ций которые бы были только в Листе или в Массиве или в последовательности...
Ты себе как представляешь ленивые unzip, partition и т.д. на основе IEnumerable<_>? Это будет приводить к материализации все последовательности, аналогично Seq.groupBy и т.д. Только в данном случае вероятность того, что найдется человек который про это забудет будет приближаться к критической отметке.
Klei
Но Seq.groupBy есть же, а этого нет.
Для ввода unzip надо будет провести кампанию аналогичную Count() > 1.
Hog
Pavel
да бесполезно... некоторые до сих пор лепят
существует поверье что для List оно быстрее
Romɑn
Круги()>1 это понятно, что тупняк
Romɑn
Но что за компания?)
Klei
Но что за компания?)
Надо будет развешивать плакаты, рассказывать на всех конфах и учебках, что `unzip >> fst >> head \ take 4 \ exists ...`` и т.д. это плохо. Правда в этот раз будет чуть по проще, ибо не будет "прошаренных", которые будут "знать", что если начальный источник ResizeArray, то все будет норм, несмотря на 5 Select, Where и прочего между ними.
Vasily
Я бы сказал , ml style concurrency