Отличная аналогия, только на вопрос не отвечает. В театре встать на стремянку даёт преимущество - улучшение видимости. А если все знают что пробег скручен то на него просто должны перестать обладать внимание, нет?
Допустим, такая ситуация - у нас есть 10 тематических коммитов, потом по результатам review принято решение переименовать метод который используется во всех них. Вы аккуратно разносите переименования по 10 комитам, чтобы было как будто написано сразу так?
Хотелось бы советов/инструментов по наименее геморройному ребейз интерактиву.
Вопрос, что понимать под моками - все test douibles или как у Фаулера:
Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
Я против вот таких моков, потому, что они не полностью реализуют контракт зависимости. Соответствено, даже при безошибочных изменениях в SUT тесты будут падать.
- матмодели. Если на вход подается два датасета и десять параметров, а на выходе еще один датасет значений в 1000 - сетапить тяжело, и отдельными ассертами неудобно тестировать.
Там код - это именно код, а не ресурсы. И это имеет значение, потому-что ресурсы, насколько я могу судить по опыту, это дешевле, чем код. Из-за регулярной структуры их проще поддерживать и проще писать
Нельзя ли организовать регулярную структуру в коде?
Напротив, появление какого-нибудь нового параметра, который нужно добавлять в payload в представленном sendReadyForDeliveryEvent потребует модификаций именно в коде теста. Поэтому здесь сильная связность тестов с тестируемым кодом, соотношение 1 к 1 и все другие
Общие вещи можно вынести в общие методы. Тогда связь будет не 1:1. В ресурсах это не получится. Так же в ресурсах, в особенности записанных автоматически, нельзя будет понять откуда взялось значение и как именно оно связано с условиями теста.
И так несколько раз по кругу. Я пытался рассказать о том, как строятся системы, почему не бывает “стандартной регистрации” и в чем риск строить mission critical систему в конструкторе сайтов, но особого эффекта это не возымело.
Если заказчик знает про риски, это зафиксировано и хочет сделать все равно на вордпрессе, почему он не может получить то, что хочет?
Достаточно понимать практику и бизнес. Как работает гугл знать в деиалях необязательно. Если у нас возникает гипотеза о том, что практика применима, то нам необязательно полностью ее брать из гугла - достаточно проверить гипотезу (поискать нет ли похожего, но для маленьких компаний, поэкспериментировать и т.д.).
Книжка дает некоторый кругозор того, как в принципе бывает и набор терминов, которые можно поискать.
Похоже, ваш мир наполнен механизмами, которые читают книжки и сразу же их в точности выполняют. В противном случае в нем были бы мыслимы люди которые могут прочитать книжку прикинуть осмысленность заимствования практик из гугл и применить нужную часть из них в своей работе.
Репо ограничивает набор запросов которые требуется качественно реализовать.
Если вы выставляете IQueriable то вы требуете от реализации успешно выполнять не только запросы, которые используются приложением но и все остальные мыслимые запросы. Соответственно подмена хранилища будет сложнее.
Оба решения обладают как достоинствами так и недостатками.
Пример кривой, но может быть рефакторинг типа добавления параметра в метод где в тестах заинлайнили неправильное значение а в коде сделали ошибку тоже какую-то.
Рефакторинг это изменение терминологии в котором написано поведение.
Есть рефакторинги с раной степенью риска (например c использованием автоматических рефакторингов), можно делать рефакторинги в два этапа (код, потом тесты). В целом проблема есть, да. Можно писать только E2E тесты и для каких-то случаев это работает и тесты не будут изменяться при рефакторинге. Но будут изменять при изменении UI.
Отличная аналогия, только на вопрос не отвечает. В театре встать на стремянку даёт преимущество - улучшение видимости. А если все знают что пробег скручен то на него просто должны перестать обладать внимание, нет?
Если все в курсе то зачем врать? Это ж все равно, что не врать?
А что за правду вы хотели донести?
А на работе кто-то запрещает чистить зубы?
А при чем тут "все равно тебе"?
Вы что, никогда не ставили будильник типа "Запустить ядерную ракету. Код доступа 645"?
Допустим, такая ситуация - у нас есть 10 тематических коммитов, потом по результатам review принято решение переименовать метод который используется во всех них. Вы аккуратно разносите переименования по 10 комитам, чтобы было как будто написано сразу так?
Хотелось бы советов/инструментов по наименее геморройному ребейз интерактиву.
Вопрос, что понимать под моками - все test douibles или как у Фаулера:
Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
Я против вот таких моков, потому, что они не полностью реализуют контракт зависимости. Соответствено, даже при безошибочных изменениях в SUT тесты будут падать.
Не вижу логики - платит то
все равно компания. И программисту и пользователям, которые будут натыкаться на эти баги и репортить, пока их не исправят.
Это уже рекординг аутпута, наверное, а не депенденси. Типа https://approvaltests.com/
Нельзя ли организовать регулярную структуру в коде?
Общие вещи можно вынести в общие методы. Тогда связь будет не 1:1. В ресурсах это не получится. Так же в ресурсах, в особенности записанных автоматически, нельзя будет понять откуда взялось значение и как именно оно связано с условиями теста.
Одно дело
Tax.Should().Be(0.12)
другое дело
Tax.Should().Be(Round(OrderTotal * Discount * TaxRate, CurrencyRounding))
Если заказчик знает про риски, это зафиксировано и хочет сделать все равно на вордпрессе, почему он не может получить то, что хочет?
Кто помнит пленочную, скукоживающуюся волнами клаву БК-0010 ставь класс
Достаточно понимать практику и бизнес. Как работает гугл знать в деиалях необязательно. Если у нас возникает гипотеза о том, что практика применима, то нам необязательно полностью ее брать из гугла - достаточно проверить гипотезу (поискать нет ли похожего, но для маленьких компаний, поэкспериментировать и т.д.).
Книжка дает некоторый кругозор того, как в принципе бывает и набор терминов, которые можно поискать.
Похоже, ваш мир наполнен механизмами, которые читают книжки и сразу же их в точности выполняют. В противном случае в нем были бы мыслимы люди которые могут прочитать книжку прикинуть осмысленность заимствования практик из гугл и применить нужную часть из них в своей работе.
Репо ограничивает набор запросов которые требуется качественно реализовать.
Если вы выставляете IQueriable то вы требуете от реализации успешно выполнять не только запросы, которые используются приложением но и все остальные мыслимые запросы. Соответственно подмена хранилища будет сложнее.
Оба решения обладают как достоинствами так и недостатками.
Пишут маленькие интеграционные тесты?
А сам файловый логгер тестировать надо?
А то, что в приложении в целом используется файловы логгер?
Пример кривой, но может быть рефакторинг типа добавления параметра в метод где в тестах заинлайнили неправильное значение а в коде сделали ошибку тоже какую-то.
Рефакторинг это изменение терминологии в котором написано поведение.
Есть рефакторинги с раной степенью риска (например c использованием автоматических рефакторингов), можно делать рефакторинги в два этапа (код, потом тесты). В целом проблема есть, да. Можно писать только E2E тесты и для каких-то случаев это работает и тесты не будут изменяться при рефакторинге. Но будут изменять при изменении UI.
Вопрос, что лучше. С учетом всех плюсов и минусов