я так это вижу - тесты прибавляют защищённости, но пожирают бюджет. И субъективно - оно того не стоит

Есть у кого хорошая аргументация против юнит тестов как таковых?

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

я так это вижу - тесты прибавляют защищённости, но пожирают бюджет. И субъективно - оно того не стоит

молдаван топит против юнит тестов

пересмотри его, он хорошо рассказывает же

ссылку?

ко всему прочему, такой код ковередж сложнодостижим

(видел проекты с пустыми тестами абы вызывало что и не падало), там как раз достигали 90%

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

так что 90% уже не получится

у меня сёдня митинх с бизнесом, они хотят 90% каверэйдж именно юнит тестами. Я считаю, они - мусор

90% кавераж это проверка гет сетов

по мне логично важные вещи чекать

кусками

но не 100%

ну вот я 10 тонн строк закомитил

проверок гет сетов

топ

и понял, что я долбаёб

выполнил план на заводе

напечатал строк кода)

хехе

по мне логично важные вещи чекать

можешь дать кейс, где юнит тест действительно очень нужен?

прям на пальцах, вот есть метод, делает то-то, тестим так-то

томушт то-то

можешь дать кейс, где юнит тест действительно очень нужен?

при фиксах легаси оч помогает

это слишком абстрактно

ну, есть у нас модуль, который считает выплату долга для бизнеса на следующие n-лет

можешь дать кейс, где юнит тест действительно очень нужен?

ну я вот я вчера портировал кусок из кишок винформс, сделал я это с костылями потому что мне надо было все сделать так, чтобы не было зависимости от System.Windows.Forms и System.Drawing. в итоге я написал тестов чтобы проверить что оно читает данные как и оригинал https://github.com/Liminiens/resx-standard/blob/master/tests/Resx.Tests/ResXDataNode_Tests.cs

иначе там только с крестом сидеть

так видно сразу если отъебнет где-то

ссылку?

https://www.youtube.com/results?search_query=Anton+Moldovan

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

блин

что за фигня?

Seq.unzip нет что ли?

https://www.youtube.com/results?search_query=Anton+Moldovan

sps

Seq.unzip нет что ли?

List.unzip << Seq.toList

у меня сёдня митинх с бизнесом, они хотят 90% каверэйдж именно юнит тестами. Я считаю, они - мусор

на f# проект?

на f# проект?

ох если бы

скажи что 90% можно обеспечить только используя measures а они только в f#. пусть выбирают

Есть у кого хорошая аргументация против юнит тестов как таковых?

Для того, чтобы они приносили реальную пользу, в них должно быть кода больше, чем в самом приложении. И времени они пожирают соответственно. И поддерживать их заебно. И если стоит цель покрытия 90% — то это выльется через 2-3 месяца в то, что тесты будут писаться на отъебись, лишь бы их актуализировать приходилось пореже

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

Я дико извиняюсь... только мельком увидел с утра - кто-то кого-то просил забанить... тут же всё обновилось и исчезло... чо было-то? :)

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

Все не так страшно. Юнит-тесты тем нужнее, чем сложнее внутренняя логика по сравнению с внешними интерфейсами

Тогда они дают профит

А вот процент покрытия как цель сам по себе нафиг не нужен

Еще один источник профита - цена косяка, детектируемого тестами.

"юнит тесты вынуждены нарушать инкапсуляцию" - а вот если их писать не в отдельном модуле, а прямо с боевым кодом (вроде в Расте так делают) то из тестов все кишочки видны

Для того, чтобы они приносили реальную пользу, в них должно быть кода больше, чем в самом приложении. И времени они пожирают соответственно. И поддерживать их заебно. И если стоит цель покрытия 90% — то это выльется через 2-3 месяца в то, что тесты будут писаться на отъебись, лишь бы их актуализировать приходилось пореже

так в теории так и должно быть. тест пишется один раз и продолжает работать и исполнять свои функции независимо от изменений в реализации

но это в теории. на практике любой PR состоит из изменений в коде и соответствующих изменений в тестах в пропорции 1:1

"юнит тесты вынуждены нарушать инкапсуляцию" - а вот если их писать не в отдельном модуле, а прямо с боевым кодом (вроде в Расте так делают) то из тестов все кишочки видны

Юнит-тесты не должны нарушать инкапсуляцию. Иначе они просто делают код более хрупким без всяких плюшек

но это в теории. на практике любой PR состоит из изменений в коде и соответствующих изменений в тестах в пропорции 1:1

Нет, конечно. Рефакторинги в тестах меняют на порядки меньше, чем в остальном коде.

Юнит-тесты не должны нарушать инкапсуляцию. Иначе они просто делают код более хрупким без всяких плюшек

юнит-тесты в принципе не могут ничего нарушать. нарушает обычно разработчик, который не может написать тестируемый код

юнит-тесты в принципе не могут ничего нарушать. нарушает обычно разработчик, который не может написать тестируемый код

Именно

Нет, конечно. Рефакторинги в тестах меняют на порядки меньше, чем в остальном коде.

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

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

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

в теории. да

в теории. да

Ну я на практике так делаю.

вы нанимаете?

вы нанимаете?

Я работаю :) Выпиливаю своими руками

в смысле, у вас вакансии есть? я бы задумался

Рано или поздно функциональное программирование ворвётся в ваш дом (с) АХ.

гыыыы :)

List.unzip << Seq.toList

Но ведь в 4 фш говорили что нет таких ф-ций которые бы были только в Листе или в Массиве или в последовательности...

Но ведь в 4 фш говорили что нет таких ф-ций которые бы были только в Листе или в Массиве или в последовательности...

Ты себе как представляешь ленивые unzip, partition и т.д. на основе IEnumerable<_>? Это будет приводить к материализации все последовательности, аналогично Seq.groupBy и т.д. Только в данном случае вероятность того, что найдется человек который про это забудет будет приближаться к критической отметке.

Ты себе как представляешь ленивые unzip, partition и т.д. на основе IEnumerable<_>? Это будет приводить к материализации все последовательности, аналогично Seq.groupBy и т.д. Только в данном случае вероятность того, что найдется человек который про это забудет будет приближаться к критической отметке.

Но Seq.groupBy есть же, а этого нет.

Но ведь в 4 фш говорили что нет таких ф-ций которые бы были только в Листе или в Массиве или в последовательности...

врут

Рано или поздно функциональное программирование ворвётся в ваш дом (с) АХ.

Адольв Хитлер??

Адольв Хитлер??

Адов

Но Seq.groupBy есть же, а этого нет.

Для ввода unzip надо будет провести кампанию аналогичную Count() > 1.

Для ввода unzip надо будет провести кампанию аналогичную Count() > 1.

да бесполезно... некоторые до сих пор лепят

да бесполезно... некоторые до сих пор лепят

Я на это и намекаю.

да бесполезно... некоторые до сих пор лепят

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

Для ввода unzip надо будет провести кампанию аналогичную Count() > 1.

Поясни?

Круги()>1 это понятно, что тупняк

Но что за компания?)

Но что за компания?)

Надо будет развешивать плакаты, рассказывать на всех конфах и учебках, что `unzip >> fst >> head \ take 4 \ exists ...`` и т.д. это плохо. Правда в этот раз будет чуть по проще, ибо не будет "прошаренных", которые будут "знать", что если начальный источник ResizeArray, то все будет норм, несмотря на 5 Select, Where и прочего между ними.

Надо будет развешивать плакаты, рассказывать на всех конфах и учебках, что `unzip >> fst >> head \ take 4 \ exists ...`` и т.д. это плохо. Правда в этот раз будет чуть по проще, ибо не будет "прошаренных", которые будут "знать", что если начальный источник ResizeArray, то все будет норм, несмотря на 5 Select, Where и прочего между ними.

Понял о чем ты

Рано или поздно функциональное программирование ворвётся в ваш дом (с) АХ.

Это я чтоли сказал?? Не помню такого

Рано или поздно функциональное программирование ворвётся в ваш дом (с) АХ.

Гопак же

Я бы сказал , ml style concurrency