Там код - это именно код, а не ресурсы. И это имеет значение, потому-что ресурсы, насколько я могу судить по опыту, это дешевле, чем код. Из-за регулярной структуры их проще поддерживать и проще писать
Нельзя ли организовать регулярную структуру в коде?
Напротив, появление какого-нибудь нового параметра, который нужно добавлять в payload в представленном sendReadyForDeliveryEvent потребует модификаций именно в коде теста. Поэтому здесь сильная связность тестов с тестируемым кодом, соотношение 1 к 1 и все другие
Общие вещи можно вынести в общие методы. Тогда связь будет не 1:1. В ресурсах это не получится. Так же в ресурсах, в особенности записанных автоматически, нельзя будет понять откуда взялось значение и как именно оно связано с условиями теста.
И так несколько раз по кругу. Я пытался рассказать о том, как строятся системы, почему не бывает “стандартной регистрации” и в чем риск строить mission critical систему в конструкторе сайтов, но особого эффекта это не возымело.
Если заказчик знает про риски, это зафиксировано и хочет сделать все равно на вордпрессе, почему он не может получить то, что хочет?
Достаточно понимать практику и бизнес. Как работает гугл знать в деиалях необязательно. Если у нас возникает гипотеза о том, что практика применима, то нам необязательно полностью ее брать из гугла - достаточно проверить гипотезу (поискать нет ли похожего, но для маленьких компаний, поэкспериментировать и т.д.).
Книжка дает некоторый кругозор того, как в принципе бывает и набор терминов, которые можно поискать.
Похоже, ваш мир наполнен механизмами, которые читают книжки и сразу же их в точности выполняют. В противном случае в нем были бы мыслимы люди которые могут прочитать книжку прикинуть осмысленность заимствования практик из гугл и применить нужную часть из них в своей работе.
Репо ограничивает набор запросов которые требуется качественно реализовать.
Если вы выставляете IQueriable то вы требуете от реализации успешно выполнять не только запросы, которые используются приложением но и все остальные мыслимые запросы. Соответственно подмена хранилища будет сложнее.
Оба решения обладают как достоинствами так и недостатками.
Пример кривой, но может быть рефакторинг типа добавления параметра в метод где в тестах заинлайнили неправильное значение а в коде сделали ошибку тоже какую-то.
Рефакторинг это изменение терминологии в котором написано поведение.
Есть рефакторинги с раной степенью риска (например c использованием автоматических рефакторингов), можно делать рефакторинги в два этапа (код, потом тесты). В целом проблема есть, да. Можно писать только E2E тесты и для каких-то случаев это работает и тесты не будут изменяться при рефакторинге. Но будут изменять при изменении UI.
А мне, наоборот, понравилось. Кратко и понятно. Правда я книжку Умняковой про иммунитет прочитал.
Единственное пожелание к оформлению поста, снабдить ссылки на исследования краткой аннотацией. И желательно чтобы были заголовками а не просто URL в тексте.
А если используются моки то по той же логике это тестирование интеграции с моками - только они сами не протестированы другими тестами и часто реализуют интерфейсы не полностью
Нельзя ли организовать регулярную структуру в коде?
Общие вещи можно вынести в общие методы. Тогда связь будет не 1:1. В ресурсах это не получится. Так же в ресурсах, в особенности записанных автоматически, нельзя будет понять откуда взялось значение и как именно оно связано с условиями теста.
Одно дело
Tax.Should().Be(0.12)
другое дело
Tax.Should().Be(Round(OrderTotal * Discount * TaxRate, CurrencyRounding))
Если заказчик знает про риски, это зафиксировано и хочет сделать все равно на вордпрессе, почему он не может получить то, что хочет?
Кто помнит пленочную, скукоживающуюся волнами клаву БК-0010 ставь класс
Достаточно понимать практику и бизнес. Как работает гугл знать в деиалях необязательно. Если у нас возникает гипотеза о том, что практика применима, то нам необязательно полностью ее брать из гугла - достаточно проверить гипотезу (поискать нет ли похожего, но для маленьких компаний, поэкспериментировать и т.д.).
Книжка дает некоторый кругозор того, как в принципе бывает и набор терминов, которые можно поискать.
Похоже, ваш мир наполнен механизмами, которые читают книжки и сразу же их в точности выполняют. В противном случае в нем были бы мыслимы люди которые могут прочитать книжку прикинуть осмысленность заимствования практик из гугл и применить нужную часть из них в своей работе.
Репо ограничивает набор запросов которые требуется качественно реализовать.
Если вы выставляете IQueriable то вы требуете от реализации успешно выполнять не только запросы, которые используются приложением но и все остальные мыслимые запросы. Соответственно подмена хранилища будет сложнее.
Оба решения обладают как достоинствами так и недостатками.
Пишут маленькие интеграционные тесты?
А сам файловый логгер тестировать надо?
А то, что в приложении в целом используется файловы логгер?
Пример кривой, но может быть рефакторинг типа добавления параметра в метод где в тестах заинлайнили неправильное значение а в коде сделали ошибку тоже какую-то.
Рефакторинг это изменение терминологии в котором написано поведение.
Есть рефакторинги с раной степенью риска (например c использованием автоматических рефакторингов), можно делать рефакторинги в два этапа (код, потом тесты). В целом проблема есть, да. Можно писать только E2E тесты и для каких-то случаев это работает и тесты не будут изменяться при рефакторинге. Но будут изменять при изменении UI.
Вопрос, что лучше. С учетом всех плюсов и минусов
Ссылка, цитата?чорт смайлик не заметилПочему большой класс оставется без тестов? Можно хотя бы E2E/Integration тест написать, который его покроет?
А почему именно TDD - это критика ж всего тестирования. А если программировать сложно - то это критика программирования.
А в чем сложность? Просто устанавливаешь состояние до, проверяешь состояние после?
Говорят, top-down возможен. Я предпочитаю mixed approach.
Ссылка, цитата?
Сначала тест. В единственном числе. Потом код. Потом следующий.
del
А мне, наоборот, понравилось. Кратко и понятно. Правда я книжку Умняковой про иммунитет прочитал.
Единственное пожелание к оформлению поста, снабдить ссылки на исследования краткой аннотацией. И желательно чтобы были заголовками а не просто URL в тексте.
А если используются моки то по той же логике это тестирование интеграции с моками - только они сами не протестированы другими тестами и часто реализуют интерфейсы не полностью
Создание экземпляра - легко, а вот целостность - не очень