Так в статье рссмотренны недостатки гит, но не рассмотрены преимущества. Может они не обо всех знают. Вопрос в том, стоило ли оно для них. Разумеется любимое детище кажется им ближе
Просто мне есть чем заняться кроме плясок вокруг системы контроля версий. Само по себе набирание командочек мне неинтересно. Для меня лучшая СКВ, которой нет.
Все нераспространенное имеет крупный недостаток по сравнению со всем распротранненным — оно не поддерживается сторонними разработчиками. Есть этот FOSSIL для Idea, VS code, VS, Eclipse и прочего?
Тесты это и есть клиентский код. Если нам что-то трудно тестировать отдельно от остального кода, это значит, что эту часть нельзя реюзать в другом контексте.
То есть все рассуждения о том, что можно было бы метрики вычислять по коду — чисто теоретические и практикой не проверены. Не встречалось ли в вашей практике такое, что теоретически казалось применимым а на практике возникали непреодолимые препяттвия? Вам тут рассказыват о подтвержденном опыте. Почему бы не попробовать найти там рациональное зерно?
Потому что в эту минуту я как раз изобретал новый способ, как перебраться через забор. Рассказать?
Расскажите, пожалуйста, — учтиво сказала Алиса.
Я расскажу тебе, как я до этого дошел, — начал Рыцарь. — Понимаешь, я сказал сам себе: "Все затруднение заключается в ногах. Голова-то до верха забора достает,- а вот ноги"… Так вот: сначала я кладу голову на верх забора — и голова моя, значит, на должной высоте; потом я становлюсь на голову и наверх поднимаются мои ноги, — значит, и они на должной высоте. Понимаешь? И тогда я уже по ту сторону забора.
Пожалуй, вы очутитесь на той стороне, если вы это проделаете, — сказала Алиса, — но вы не думаете разве, что это будет довольно больно?
Я еще не пробовал! — серьезно сказал Рыцарь, — так что наверное сказать не могу. Но я боюсь, действительно, немножко будет больно.
Эта мысль так, очевидно, огорчила его, что Алиса поспешила переменить предмет разговора.
С точки зрения сферического юнит-тестирования в вакууме — безусловно, да
Ok. Хорошо, мы наверное говорим о разных юнит тестах. Давайте юнит тест по вашему определению называть сферическим, а юнит тест по Фаулеру (см выше в т.ч. sociable) практическим.
Однако на практике как-то уж принято зависимости на стандартную библиотеку и рантайм не изолировать.
То есть по вашему правило практический изоляции это стандартность? Т.е. все стандартное не изолируем все нестандартное изолируем иначе тест не юнит?
Ну конечно не будет, вам и мокать-то эту зависимость не обязательно. Проблема только в том, что ваш тест не будет изолирован и не будет, по определению, юнит-тестом.
Хорошо, как вычснилось мы говорим о разных вещах. Оно не будет сферическим юнит тестом. Фаулеровским юнит тестом оно будет.
Если у вас есть идеальная структура то вы, оченвидно, не можете получить полезного фидбека ни от чего.
Однако сам по себе тезис что есть спроектированная идеальная стркутура мне кажется сомнительным. Почему я считаю фидбек от тестов полезным, я уже рассказывал.
Если ваш модуль Х при выполнении какого-то метода дергает метод модуля Y, то это зависимость.
Отлично. Должен ли я мокать System.String, чтобы вы назвали мой тест юнит тестом?
То есть вместо того, чтобы держать детали реализации внутри, вы их выставляете напоказ.
Если что-то снаружи абсолютно невидимо, то оно мне не будет мешать тестировать. Если оно снаружи видимо значит оно является частью интерфейса, только неявной. Я просто ее сделаю явной и абстрактной.
Во-вторых я могу выделить из тестируемого кода дополнительный модуль. Если мне легко и интересно его тестировать отдельно, значит для этого есть отдельные требования. И да деталь реализации станет интерфейсом. Только вложенного модуля.
Ну так, смотрите. У вас есть система, которая структурирована согласно требованиям предметной области. Вы пытаетесь написать для нее тесты. Получается плохо. Значит, в чем проблема?
В том, что на самом деле мы не заметили как в структуру просочились технические аспекты. Если есть предметная область и все — то тестировать обычно легко.
Так можно не увидеть зависимость — тест покажет, что она реально нужна. Дополнительно тест еще проверит корректнось модуля и покажет где именно ошибка. Дополнитльно он еще будет проверять чтобы другие люди потом не вносили зависимостей.
Если у вас есть другой опробованный процесс разработки который позволяет сделать то же самое втоматизировано, мне хотелоь бы услышать о вашем опыте. например каким инструментом в пользуетесь для подсчета звисимостей и как он встроен в CI
Но если метод, который выполняет расчет, использует некую зависимость, то вы не сможете протестировать данный метод, не мокнув зависимость. А чтобы ее мокнуть — о ней надо знать. Если тест о зависимостях не знает, то он просто будет интеграционным.
Я не знаю, как вы определяете моканье, я для простоты буду называт моканьем ниже создание любых тест-специфичных реализаций.
См выше sociable unit test
Еще есть проблема с определением того, что такое "зависимость" — почему мы не мокаем System.String?
Если тест использует что-то внутри себя, что не является частью требований И это не доставляет проблем — то я это никогда не мокаю.
Если это доставляет проблемы, то я переразбиваю юниты так, чтобы проблемная часть была отдельно (типа обращение к субд). И тогда она становится частью интерфейса модуля.
Конкретный тест может вообще не знать о зависимости, так как создание объекта со всеми замокнутыми зависимостями выносится в отдельный метод и тест работает с ними как с юнитами не зная про зависимости.
Расчетный модуль может вообще ничего не знать об оповещениях. Он может просто рассказывать подписчикам о событиях в расчете, а они уже сами могут решать передавать ли оповещения и в каком формате.
Выглядит прикольно. Есть ли какие-то сравнения по качеству и скорости? Напишете статью на хабр?
Почему "крипто"?
Не зависить от связи и при этом иметь возможность сохранять промежуточные состояния своей работы
git pull
git push
а как сделать, чтобы напрямую к локальному репозиторию нельзя было подключиться?
насколько я понял в ситуации вы детально не разбирались, а просто услышали историю на интервью?
Так в статье рссмотренны недостатки гит, но не рассмотрены преимущества. Может они не обо всех знают. Вопрос в том, стоило ли оно для них. Разумеется любимое детище кажется им ближе
Обектная база данных. Никаких прослоек :)
Просто мне есть чем заняться кроме плясок вокруг системы контроля версий. Само по себе набирание командочек мне неинтересно. Для меня лучшая СКВ, которой нет.
Все нераспространенное имеет крупный недостаток по сравнению со всем распротранненным — оно не поддерживается сторонними разработчиками. Есть этот FOSSIL для Idea, VS code, VS, Eclipse и прочего?
Воспользуйтесь ORM или объектной базой данных. Это проблема конкретных API а не ООП
Кстати, тогда у вас есть модуль "сумматор-вместе-с-фабрикой" которым можно сносно пользоваться. А сумматор отдельно не реюзабелен.
Хотя нет. Это если толко тест проверит, что часть фабрики относящаяся к сумматору, может быть использована отдельно.
Тесты это и есть клиентский код. Если нам что-то трудно тестировать отдельно от остального кода, это значит, что эту часть нельзя реюзать в другом контексте.
То есть все рассуждения о том, что можно было бы метрики вычислять по коду — чисто теоретические и практикой не проверены. Не встречалось ли в вашей практике такое, что теоретически казалось применимым а на практике возникали непреодолимые препяттвия? Вам тут рассказыват о подтвержденном опыте. Почему бы не попробовать найти там рациональное зерно?
Ok. Хорошо, мы наверное говорим о разных юнит тестах. Давайте юнит тест по вашему определению называть сферическим, а юнит тест по Фаулеру (см выше в т.ч. sociable) практическим.
То есть по вашему правило практический изоляции это стандартность? Т.е. все стандартное не изолируем все нестандартное изолируем иначе тест не юнит?
Хорошо, как вычснилось мы говорим о разных вещах. Оно не будет сферическим юнит тестом. Фаулеровским юнит тестом оно будет.
Если у вас есть идеальная структура то вы, оченвидно, не можете получить полезного фидбека ни от чего.
Однако сам по себе тезис что есть спроектированная идеальная стркутура мне кажется сомнительным. Почему я считаю фидбек от тестов полезным, я уже рассказывал.
Какой программой вы пользуетесь, как часто ее запускаете и как анализируете ответы?
Отлично. Должен ли я мокать System.String, чтобы вы назвали мой тест юнит тестом?
Если что-то снаружи абсолютно невидимо, то оно мне не будет мешать тестировать. Если оно снаружи видимо значит оно является частью интерфейса, только неявной. Я просто ее сделаю явной и абстрактной.
Во-вторых я могу выделить из тестируемого кода дополнительный модуль. Если мне легко и интересно его тестировать отдельно, значит для этого есть отдельные требования. И да деталь реализации станет интерфейсом. Только вложенного модуля.
В том, что на самом деле мы не заметили как в структуру просочились технические аспекты. Если есть предметная область и все — то тестировать обычно легко.
Так можно не увидеть зависимость — тест покажет, что она реально нужна. Дополнительно тест еще проверит корректнось модуля и покажет где именно ошибка. Дополнитльно он еще будет проверять чтобы другие люди потом не вносили зависимостей.
Если у вас есть другой опробованный процесс разработки который позволяет сделать то же самое втоматизировано, мне хотелоь бы услышать о вашем опыте. например каким инструментом в пользуетесь для подсчета звисимостей и как он встроен в CI
Я не знаю, как вы определяете моканье, я для простоты буду называт моканьем ниже создание любых тест-специфичных реализаций.
Если тест использует что-то внутри себя, что не является частью требований И это не доставляет проблем — то я это никогда не мокаю.
Если это доставляет проблемы, то я переразбиваю юниты так, чтобы проблемная часть была отдельно (типа обращение к субд). И тогда она становится частью интерфейса модуля.
Конкретный тест может вообще не знать о зависимости, так как создание объекта со всеми замокнутыми зависимостями выносится в отдельный метод и тест работает с ними как с юнитами не зная про зависимости.
Расчетный модуль может вообще ничего не знать об оповещениях. Он может просто рассказывать подписчикам о событиях в расчете, а они уже сами могут решать передавать ли оповещения и в каком формате.