Не совсем бизнес логика в традиционном понимании, но и не инфраструктурная вещь.

ну можно сказать утилитарное

ну можно сказать утилитарное

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

о круто и как вам?

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

угу

я думал на досуге выучить системный язык еще какой, С++ 14-17 выбирал и Раст

ну С++ у меня базовые знания есть какие-то уже, а вот Rust с нуля надо учить

угу

Но из плюсов - даже очень наивный и тупой код даёт очень приличную производительность за которую в других языках приходится биться.

я думал на досуге выучить системный язык еще какой, С++ 14-17 выбирал и Раст

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

Надо его воспринимать как некое странное слияние си и ML-подобного языка с линейными типами и тайпклассами.

И проектировать приложение соответственно.

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

это у меня мозги плавятся или шо

это у меня мозги плавятся или шо

побочный эффект пхп

вот тайпклассы мне там понравились в расте

это у меня мозги плавятся или шо

Это опенспейс зло

Это опенспейс зло

у нас не опенспейс

тут комнатки по 3-5 чел

Неужели три человека могут создать столько шума, чтобы сидеть в наушниках?

Нет, просто музыку слушаю)

Ужас!

написал тесты, выдался диалог из ряда: -ты чо совсем тупой, ты зачем сюда посылаешь строки, но просто разные? -два кейса, где одна структура и разные строки, я хочу проверить что жсон собирается в зависимости от содержания, а не как-то по рандому -ты чо это же одинаковый кейс -а как бы ты протестил функцию, которая принимает число и говорит положительное ли оно? -только три кейса: -1, 0 и 1

я мб рили тупой, но если я хочу побольше кейсов покрыть, то эт хуево или шо

и почему достаточно 3 кейсов для функции, которая говорит что число положительное, тоже понять не могу

над подумать

Самое время предложить им property-based тестирование!

Я кстати предложил

Я кстати предложил

Ты чо совсем тупой?

Ты чо совсем тупой?

походу(

и почему достаточно 3 кейсов для функции, которая говорит что число положительное, тоже понять не могу

Напиши им функцию, которая только эти три варианта обрабатывает, а в остальных случаях кидает исключение.

Напиши им функцию, которая только эти три варианта обрабатывает, а в остальных случаях кидает исключение.

тут тесты пишутся от реализации, а не от спецификации

на такой кейс скажут "ты рили тупой"

:(

походу(

ну, я просто продолжил мысль - если ты "вручную" несколько разных строк посылаешь, то чем это будет отличаться от N строк при property-based?

Я вообще не понимаю, зачем такую функцию тестить.

ну, я просто продолжил мысль - если ты "вручную" несколько разных строк посылаешь, то чем это будет отличаться от N строк при property-based?

ну мне на это вот и пожаловались

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

Поэтому переходи сразу к интеграционным!

Покажи им доклад Молдована.

Пересади на F#.

К пятнице управишься?

А вот с property based testing не ясно — как их правильно писать, чтоб в тестах не дублировать полностью логику?

К пятнице управишься?

хотя бы к следующей! :)))

А вот с property based testing не ясно — как их правильно писать, чтоб в тестах не дублировать полностью логику?

А потом выясняется, что в логике в тестах была ошибка :D

Как я понял, в тестах должна быть верификация, а не полностью логика. Но я тупой.

Пересади на F#.

должно быть нетрудно. У них вроде open minded команда, да и переход с пыхи на фшарп не такой уж радикальный

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

А вот с property based testing не ясно — как их правильно писать, чтоб в тестах не дублировать полностью логику?

надо свойства тестировать типа отрицательное + отрицательное = отрицательное, положительное + положительное = положительное, положительное - отрицательное = положительное

и всё такое

должно быть нетрудно. У них вроде open minded команда, да и переход с пыхи на фшарп не такой уж радикальный

Как я понял, в тестах должна быть верификация, а не полностью логика. Но я тупой.

я вот пока тока вижу это так примерно: тестируемая функция выполняет логику, а мы эту логику дробим на несколько простых составляющих, которые видимо и являются свойствами. И потом тестируем)

но возможно я как-то не так вижу это

надо свойства тестировать типа отрицательное + отрицательное = отрицательное, положительное + положительное = положительное, положительное - отрицательное = положительное

и как это применить к функции, которая определяет знак числа?)

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

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

кидай ссылку

о, в финку опять ищут пхпшника на 4к евро

кидай ссылку

https://fsharpforfunandprofit.com/posts/property-based-testing/

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

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

на большой овер9999 свойств

там сложно будет

пока тесты напишешь можно всё приложение переписать

Поэтому надо где-то посередение!

https://fsharpforfunandprofit.com/posts/property-based-testing/

спс

Я всё понимаю, но проперти тестирование для функции isPositive -- это ж маразм. Проще открыть метод и прочитать одну строчку кода.

и почему достаточно 3 кейсов для функции, которая говорит что число положительное, тоже понять не могу

Сколько угодно можно писать, но лучше ограничиваться хорошо известными значениями и значениями на границах. Типа, проверяешь сортировку на пустом массиве, из одного элемента и из двух. Большинство ошибок уже здесь и выцепишь. А вот 5 элементов или 7 уже разницы нет.

Сколько угодно можно писать, но лучше ограничиваться хорошо известными значениями и значениями на границах. Типа, проверяешь сортировку на пустом массиве, из одного элемента и из двух. Большинство ошибок уже здесь и выцепишь. А вот 5 элементов или 7 уже разницы нет.

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

на гошечке пишешь хрен поймёшь же оно пуляет куда-нибудь или нет

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

ну и вообще функция принимает interface{}

как её тестировать то

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

Многие тесты — многие печали. Всякий рефакторинг из быстрого и приятного занятия превращается в медленное и мучительное. Код переписал, сломалось триста тестов. Уж лучше бы сломалось сто, всё легче.

Многие тесты — многие печали. Всякий рефакторинг из быстрого и приятного занятия превращается в медленное и мучительное. Код переписал, сломалось триста тестов. Уж лучше бы сломалось сто, всё легче.

тут код не рефакторится, насколько я понимаю

Ну это на будущее. Тесты то для этого пишут, чтобы потом рефакторить можно было как бы безопасно.

Ну это на будущее. Тесты то для этого пишут, чтобы потом рефакторить можно было как бы безопасно.

Ну так рефакторинг это изменение реализации без изменения спецификации. Вот я и проверил что спецификация правильно выполнена и от разных строк ничего не падает. Тем более я всего 2 или 3 раза эту штуку написал.

Ну так рефакторинг это изменение реализации без изменения спецификации. Вот я и проверил что спецификация правильно выполнена и от разных строк ничего не падает. Тем более я всего 2 или 3 раза эту штуку написал.

где-то я слышал что это изменение структуры кода / кода в целом без изменения функционала

а изменение реализации может изменить функционал (если спецификация покрывает не все кейсы)

https://github.com/dotnet/fsharp/pull/6805#issuecomment-578721290 > dsyme > Note I'm not particularly interested in this change supporting the SRTP-laden code that does (largely pointless) over-abstraction of code in the name of "maximal sharing" or simulating category theory - this tends to serve little actual value and makes code highly obscure, and SRTP was never designed for these purposes. Indeed if possible I'd prefer to disallow or deprecate that kind of code.

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

Ну фсё, закапывайте фшарп.