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