Хорошо, предположим всё так. Т.е. я не должен писать

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

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

Вы всё еще не поняли. У меня отношение 10% интерфейса - публичная, 90% приватная В среднем каждая их функций публичного интерфейса последовательно вызывают 10 функций приватного интерфейса Предлагаете мне в слепую писать 10 функций перед тем как их тестировать?

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

Суть приватных функций - реализовать публичный интерфейс. Публичный интерфейс это контракт. Юнит тест класса тестирует контракт. В идеальном исполнении

Где тут гугл-то вообще?

ну выше, не вы, другие мол так в гугл руководстве написано. мол приватные методы не тестируют... Просто забавно, значит Линуса хейтят мол он там придумал какую то мантру и ее повторяет. Зато вот тестировать приватные кишки не нужно ибо гугл же...

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

Гугл не первый это придумал и не единственный. Плюсовое гуглоруководство вообще в целом лучше критически воспринимать, если речь о современных плюсах и новых проектах

А как насчет процесса разработки? Мои последние вопросы именно по разработке приватной части. Как мне разрабатывать если тесты не могу писать?

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

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

Вы приватную часть зачем пишете? Чтобы реализовать публичный интерфейс. Сделайте тесты публичного интерфейса и покроете приватную часть. Если что-то не покрывается тестами публичного интерфейса, то скорее всего это не нужно вообще

АААААААААА вы вообще не читаете

Спасибо, да, это мой поинт

Нет. скажем у вас Уарт пиу пиу сделал и все правильно, но ДМА буфер скажем не был сброшен в ноль или еще чего. Или я должен был кишки на ружу вытаскивать.

МНЕ ПИСАТЬ В СЛЕПУЮ 10 ФУНКЦИЙ ЧТОБ ТЕСТИРОВАТЬ 1 ФУНКЦИЮ? Извините за капс, это скудоумие какое-то

По-моему это вы не читаете. " Я разрабатываю привантую часть, как ее тестить" "Тестите публичную, вы же из нее всю приватную вызываете напрямую" "ААААА, вы не читаете!!!"

приведи пример, код, написанный по принципам ооп, у которого 10% функционала в классах - приватные

У этой одной функции есть какой-то набор пре и посткондишенов. Покрывайте их тестами. 10 там будет функций или 20 уже не важно

Я все разы говорил, что реализация/приватная часть - 90%. Пожалуйсте, прочитайте уже наконец то мои сообщения

Вы же осознаете, что публичная это приватная+что-то еще?

Имхо надо оффтопить, это уже просто холивар.

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

:))

В контексте этого диалога "приватная часть" это процент приватных функций/кода в приватных функций (абсолютно не важно, дело немного в другом) по отношению к общему количество функций/общему объекму кода

Да какая разница какой процент в строках кода? Есть некоторый функционал, доступный через публичный интерфейс. Тесты надо к функционалу писать, а не к строкам кода

Еще раз. Как мне разрабатывать?

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

Пиздец, нету слов. Мне писать 100000 строк кода в слепую?

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

Что значит "в слепую"? Вы приватную часть просто так пишете, чтобы была? Или все таки чтобы публичный интерфейс реализовать?

Лучше разбить класс на меньшие тогда

Выйди из чата

Согласен, я и сказал выше что возможно проблема с декомпозицией

у тебя публичный метод А, он принимает строку "здарова" и возвращает строку "пока". Тебя не должно волновать как оно работает, тебя волнует что на "здарова" возвращается "пока"

Юнит тест тестирует некоторый атомарный и семантически завершённый кусок логики. Приватный он или нет, является ли частью класса или нет — дело десятое

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

Вы бы рекомендовали тестировать приватные методы класса?

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

>при правильном проектировании Вот в этом и суть. Задача появилась у тестировщика-аутсорсера, менять исходный код нельзя, ничего нельзя. Какой есть код, с тем и приходится работать

Если этот приватный массив потом никаким образом не влияет на пользовательский код, то непонятно в чем вообще смысл этого класса. Если влияет, то есть точка где можно увидеть эффект от этого приватного метода. Разве нет?

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

По моему опыту некоторый код вообще не возможно покрыть тестами. Либо можно, но от этого потом будет больше боли.

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

Без рефакторинга*

Тестируют инвариант! чтобы он был всегда валиден. как выше написали, что-то сделали, инвариант изменился, нам нужно написать тест, который скажет что если мы делаем A() у нас все хорошо. кишки наружу мы не хотим вытаскивать. Мы делаем рефакторинг (скажем вообще алгоритма в кишках). и запускаем тесты. и можем судить рефакторинг удачен или нет. ибо мы знаем что инвариант протестирован, он в порядке.

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

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

И наплодить новые сущности и куча новых "файл_нэйм.хпп"?

если у вас условные 10клок, вы уже 100% чего только не наплодили. осталось только по нормальному напложенное оформить :)

Да иногда тесты переписывают. Ибо может меняться как и публичный интерфейс так и что-то другое. НИКТО еще ниразу не написал софт, класс или что-то еще с первого раза никто! даже блин на стандарт посмотрите, то одно забыли, то другое не учли. а там вроде не бараны сидят. А что говорить про простых человеков? прям простых, которые ходят на какой нибудь завод и пишут код, которым не упало читать многотомники от гугла. потому что они простые люди, пишут код, чтобы получить зарплату. да они пишут тесты, то се... но без вот А давайте вспомним Геделя и бла бла бла... нет.

Видишь, ты решил всё за меня и рассудил по себе

Я где-то написал, что тесты не должны меняться? Возьмите соотношение ТС 10/90. Тесты публичного интерфейса будут меняться в девять раз реже

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

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

Полностью согласен

Да где же подгорело? Как-то очень вы склонны приписывать мне то чего я не говорил и не делал. Третий раз за 10 сообщений

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

Вопрос в частоте и масштабах переписывания этих тестов, а не в изменении тестов в принципе

Ну он влияет, но напрямую-то никак не доступен) А нужно проверить именно логику, по которой этот массив заполнился

Да разрабатывай ты как хочешь...

Я не думаю, что здесь учитываются ситуации, когда тесты неверны. Иначе мы сейчас начнём говорить, что тесты писать не надо, потому что тесты также могут содержать ошибки, быть неполными, отнимать время, которое можно потратить на полировку проекта и т.д. Здесь берётся ситуация "Тесты всегда верны. Тесты всегда полны. Решаем, нужно ли тестировать приватную часть юнита или нет." Если публичная часть юнита содержит сет определённых граничных случаев, а приватная часть не смогла ограничить себя этим сетом, то это проблема приватной части. Если не получается иначе, то нужно "запланировать" изменение публичной части. И вместе с ней изменить и приватную и тесты.