Но нотки здравого смысла в этом есть

Допустим вы нашли баг в неэкспортируемой функции - нужно писать тест на нее, это нормально

Это ненормально и вообще концептуально неверно и неправильно. Если в юнит-тесте мы можем влезть в потроха реализации, это значит что и юнит тест написан неправльно, и код написан тоже неправильно раз такое можно сделать.

Юнит тест может иметь доступ к внутренним частям объекта - это нормально.

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

Простые и читаемые тесты куда важнее эфемерного требования тестировать только внешние интерфейсы

Вообще не имеет смысла тестировать ничего internal

Во-первых, все тесты поломаются, если кто-то что-то порефакторит

Во-вторых, это происходит, если код - лапша и цикломатическая сложность делать код недостижимым для теста

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

а tdd вообще работает для чего-то отличного от тривиальщины?

Да

Как раз для нетривиальщины и работает

Да

а можно чуть подробнее рассказать как?

А что именно непонятно?

В-третьих, это нарушает инкапсуляцию, и три принципа из solid

Вы пишете тесты, потом код

ну вот пишу я что-то. накатал тесты, потом код. а потом оказалось, что требования поменялись

ну или просто идея нерабочая

ну вот пишу я что-то. накатал тесты, потом код. а потом оказалось, что требования поменялись

"software entities … should be open for extension, but closed for modification

Ничего не нарушает. Это же тесты - там другие правила, не путайте. Ещё скажите, что DRY нарушают.

ну вот пишу я что-то. накатал тесты, потом код. а потом оказалось, что требования поменялись

Тут тесты как раз помогают

"software entities … should be open for extension, but closed for modification

и?

Меняете тесты и все

Тут тесты как раз помогают

ну так тесты для чего? задача поменялась, надо другие тесты

получается, что мы 2 раза писали зря: сначала тесты, потом код.

Ничего не нарушает. Это же тесты - там другие правила, не путайте. Ещё скажите, что DRY нарушают.

DRY актуально и для тестов, один тест тестирует что-то одно один раз

получается, что мы 2 раза писали зря: сначала тесты, потом код.

Так это в любом случае будет

Хоть сначала тесты потом код, хоть наоборот

Так это в любом случае будет

с чего это вдруг? сначала пишем код, потом покрываем тестами. если мы на этапе написания кода поняли что идея нерабочая - просто переписываем код, а не тесты+код

с чего это вдруг? сначала пишем код, потом покрываем тестами. если мы на этапе написания кода поняли что идея нерабочая - просто переписываем код, а не тесты+код

а как же TDD

с чего это вдруг? сначала пишем код, потом покрываем тестами. если мы на этапе написания кода поняли что идея нерабочая - просто переписываем код, а не тесты+код

Это можно понять на этапе написания тестов быстрее

и?

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

Если вы тестируете идеи - стоит задуматься о необходимости тестов

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

Если надо просто расширить, это не должно ломать тесты

Если вы тестируете идеи - стоит задуматься о необходимости тестов

так вот об этом и речь: мы написали кучу тестов, а потом уперлись в какое-то ограничение языка, например.

Значит у вас плохо с экспертизой

так вот об этом и речь: мы написали кучу тестов, а потом уперлись в какое-то ограничение языка, например.

Так какая разница тогда? Тесты писать или код?

Всё равно переписывать

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

чтобы далеко не ходить: например, мы пишем какой-нибудь умножатель матриц. написали кучу тестов, начали писать код и поняли что оно неприемлемо медленно.

Темы у вас останутся

чтобы далеко не ходить: например, мы пишем какой-нибудь умножатель матриц. написали кучу тестов, начали писать код и поняли что оно неприемлемо медленно.

Так тесты останутся) а код оптимизируете

Реализацию поменяете

чтобы далеко не ходить: например, мы пишем какой-нибудь умножатель матриц. написали кучу тестов, начали писать код и поняли что оно неприемлемо медленно.

И что? Есть у нас тип Matrix, интерфейс Multiplyer, чтобы там не менялось внутри, тесты все равно должны продолжать работать

народ, а как можно бахнуть "дешешо и сердито" взаомодействие между процессами по сети?

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

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

у меня есть "мамка" и "дети", дети постоянно шлют пакеты на мамку

Так тесты останутся) а код оптимизируете

оох... вы цепляетесь за частности. причина может быть иной.

народ, а как можно бахнуть "дешешо и сердито" взаомодействие между процессами по сети?

Udp

Udp

а более высокоуровневое? ?

не охото это все с нуля реализовывать

а более высокоуровневое? ?

Grpc

охото просто структуру кинуть, структуру получить

Если клиенты не мобильные, то используй grpc

Udp

а и кидаться не больше mtu-28 байт?

а и кидаться не больше mtu-28 байт?

Да

у меня есть "мамка" и "дети", дети постоянно шлют пакеты на мамку

а какие гарантии/требования ннада?

Но все мои знакомые против grpc

Да

а потом вспомнить про pmtu и фрагментацию

и понеслось ))

а потом вспомнить про pmtu и фрагментацию

Тогда quic

Но удп решает вопросы, атвичаю

Но удп решает вопросы, атвичаю

вопросы packet loss?

охото просто структуру кинуть, структуру получить

какой размер сообщеньки? где клиенты? допустимы ли потери? )

вопросы packet loss?

Не, это слишком низко для udp

Не, это слишком низко для udp

но вполне больно для приложеньки. при том, что потери udp возможны даже на loopback )

какой размер сообщеньки? где клиенты? допустимы ли потери? )

без потери, размер "пакета" около 2-3 кб

а вот насколько быстро будут доставлены "пакеты", не критично

ERROR: S client not available

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

я уже прикидываю gob + tcp

зачем? почему не json + http?

зачем? почему не json + http?

ему структурки хочется

а json будет жирный

кто нибудь знает как в logrus сделать пересоздние файла логов каждый день?

народ, а как можно бахнуть "дешешо и сердито" взаомодействие между процессами по сети?

самый дешевый и сердитый в плане разработки из всего, что мне встречалось - zmq но он есть только в виде биндингов вернее, есть и в виде pure go, но в ограниченной функцинальности, и надо изучать, хватит ли ее для твоих задач

кто нибудь знает как в logrus сделать пересоздние файла логов каждый день?

Вроде никак. У них концепция, что такими операциями должен заниматься logrotate

Вроде никак. У них концепция, что такими операциями должен заниматься logrotate

logrotate не умеет этого без поддержки приложения. так что надо какой-то внешний логгер использовать

самый дешевый и сердитый в плане разработки из всего, что мне встречалось - zmq но он есть только в виде биндингов вернее, есть и в виде pure go, но в ограниченной функцинальности, и надо изучать, хватит ли ее для твоих задач

честно - zmq ужасен.

у нас не просили прекрасное

zmq наводит на меня тоску ?

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

у нас не просили прекрасное

нуу... он создает больше проблем, чем счастья

это вы называете "дешевым в разработке"? ?

да, я называю это дешевым в разработке

http + msgpack

без потери, размер "пакета" около 2-3 кб

а чем тебе не нравится net/rpc?

да, я называю это дешевым в разработке

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

избыточно, мне только структуры в одну сторону кинуть

избыточно, мне только структуры в одну сторону кинуть

тогда udp

udp это траханье с доставкой ?

тогда udp

оно не влезет в 1 пакет

и ему гарантии ннада

оно не влезет в 1 пакет

или пожать, или jumbo frames включить

udp это траханье с доставкой ?

ты не просил доставку, ты просил отправку

или пожать, или jumbo frames включить

jumbo не существует в интернетах )

в интернетах и с udp проблема

udp это траханье с доставкой ?

тебе в lan ннадо или через интернеты?

и так и так

в интернетах и с udp проблема

да даже не в интернетах с jumbo проблемы.

какие?!