Если у вас обычный сеттер без логики — вы пишете сеттер безо всяких тестов.
В моем предcтавлении в классическом TDD не пишут код, пока не упал тест. То есть сеттер я не могу написать без упавшего теста.
Но обычно сеттер нужен не для того, чтобы установить какое-то значение и радоваться этому. А чтобы это как-то повлияло на поведение.
Т.е. я пишу тест "если превышена максимальная глубина стека то выдается эксепшн" а не "если я задаю максимальную глубину стека, то она задана"
потому что все равно нужно покрывать юнит-тестами то, что обычно не надо покрывать, например сеттеры.
Мне кажется из TDD этого не следует. Т.е. сеттеры обычно покрываются в любом случае но не специально предназначенными для этого тестами. Что с TDD что без него.
Централизованое хранилище с возможностью строить запросы
Не требует изменения кода
Есть возможность приоритезации, описания трудоемкости, разные состояния и т.д.
Готовые инструменты визуализации в виде графиков и досок
Мой выбор:
TODO для локальный проблем текущего фичабагабранча/глючных прототипов
TODO для неочевидных мест которые зависят об багов (с указанием конкетного бага, и с указанием в баге конкретного места с TODO которое надо потом почистить)
ничего — для очевидного инженерного долга (если это будет проблемой, кто-то следующий почистит, когда это станет возможно)
я нисколько не сомневаюсь что где-то там в прекрасном мире
И прочие розовые единороги.
Вот тут я не понимаю что именно вы хотите сказать — то, что такого не бывает, или у вас есть какие-то особенности, по которым именно у вас этого не будет?
возможно технология эта в большинстве случаев просто не работает
Лично меня обычно интересует, работает ли это в моем случае, а не в большинстве (достаточно ли у меня интеллекта, чтобы отличить от подделки, сделать самому или выбрать готовое). Возможно в большинстве случаев то, что люди называют словом "лекарство" не работает — меня интересует могу ли я отличить лекарства которые работают от тех, которые не работают.
Есть наниматели которые позволяют писать тексты, соглашаются с оценками команды и т.д. возможно вы с ними просто не сталкивались. Если вы сами понимаете что тесты нужны почему вы отказываете в этом другим людям?
Обычно в таком случае много багов. Баг дошедший до продакшена стоит сравнительно дорого. Если менеджеру это важно то можно ему показать мере принятые в вашей команде процедуры обратной связи
Коммент относится к формуле но остальные части очевидны. Комментарий необходим только части формулы которая относится к компенсации накладных расходов операций с наличностью. Константа имеет единственное предназначение — для использованияв в этой компенсации. Поэтому я предложил назвать ее попонятней — из ее названия модно вывести назначение куска формулы. Ещё можно вывести этот кусок формулы в функцию с говорящим именем.
Так я сейчас не говорю что надо полностью избавляться. Коммент в данном случае скрыл плохое наименование переменной / константы. Имхо достаточно ее переименовать и, может быть, прокомментировать только ее (если она уже не документирована как-то — например, в месте где она вводится, в тесте или типа того).
Тут есть нескоро моментов. Если получится копия реализации, значит пытались назвать функцию не по тому "что" она делает а по тому "как" она эта делает — если по размышлении не получается выделить "что" то можно посмотреть вариант просто заинлайнить (getCustomers().OrderBy(x => x.BirthDay) для меня читаемее чем getCustomers и не сильно отличается чем getCustomersOrderedByBirthDay. Очень длинное отражающее назначение название часто сигнал что необходим рефакторинг.
Информационные системы — это моделирование. Модель это нечто, что отвечает на вопросе о некотором аспекте реального мира вместо реального мира. Информационная система должна отвечать на вопрос "какое имя абонента" вместо того чтобы каждый раз спрашивать у абонента. Именно поэтому как только мы немножко пошевелил ваш пример про телефонную книжку, чтобы сделать его более реальным оттуда вылез абонент. Неважно будет это отношение или класс — человеку удобно думать в в этих терминах. Просто у каждой среды моделирования есть свои ограничения.
С моей точки зрения, если для чего-то не пишутся тесты, то для разработки этого не используется TDD.
В моем предcтавлении в классическом TDD не пишут код, пока не упал тест. То есть сеттер я не могу написать без упавшего теста.
Но обычно сеттер нужен не для того, чтобы установить какое-то значение и радоваться этому. А чтобы это как-то повлияло на поведение.
Т.е. я пишу тест "если превышена максимальная глубина стека то выдается эксепшн" а не "если я задаю максимальную глубину стека, то она задана"
Мне кажется из TDD этого не следует. Т.е. сеттеры обычно покрываются в любом случае но не специально предназначенными для этого тестами. Что с TDD что без него.
Расстроенный депрессивный майор?
Или, например, зеркало для распознавание вампиров
Таск в багтрекере
Мой выбор:
Вот тут я не понимаю что именно вы хотите сказать — то, что такого не бывает, или у вас есть какие-то особенности, по которым именно у вас этого не будет?
Лично меня обычно интересует, работает ли это в моем случае, а не в большинстве (достаточно ли у меня интеллекта, чтобы отличить от подделки, сделать самому или выбрать готовое). Возможно в большинстве случаев то, что люди называют словом "лекарство" не работает — меня интересует могу ли я отличить лекарства которые работают от тех, которые не работают.
Есть наниматели которые позволяют писать тексты, соглашаются с оценками команды и т.д. возможно вы с ними просто не сталкивались. Если вы сами понимаете что тесты нужны почему вы отказываете в этом другим людям?
Обычно в таком случае много багов. Баг дошедший до продакшена стоит сравнительно дорого. Если менеджеру это важно то можно ему показать мере принятые в вашей команде процедуры обратной связи
А сколько аджайлов разных вы видели? Были это снговые или западные компании?
Коммент относится к формуле но остальные части очевидны. Комментарий необходим только части формулы которая относится к компенсации накладных расходов операций с наличностью. Константа имеет единственное предназначение — для использованияв в этой компенсации. Поэтому я предложил назвать ее попонятней — из ее названия модно вывести назначение куска формулы. Ещё можно вывести этот кусок формулы в функцию с говорящим именем.
Так я сейчас не говорю что надо полностью избавляться. Коммент в данном случае скрыл плохое наименование переменной / константы. Имхо достаточно ее переименовать и, может быть, прокомментировать только ее (если она уже не документирована как-то — например, в месте где она вводится, в тесте или типа того).
Возможно, дополнить документированием константы. Все кроме нее предназначения уже выражено кодом. Например, то, со она применяется к наличным
Тут есть нескоро моментов. Если получится копия реализации, значит пытались назвать функцию не по тому "что" она делает а по тому "как" она эта делает — если по размышлении не получается выделить "что" то можно посмотреть вариант просто заинлайнить (getCustomers().OrderBy(x => x.BirthDay) для меня читаемее чем getCustomers и не сильно отличается чем getCustomersOrderedByBirthDay. Очень длинное отражающее назначение название часто сигнал что необходим рефакторинг.
CacheOperationsCostCompensation?
Мне кажется что коммент тут компенсирует не отражающее значение название константы CashDiscount.
И судя по всему тут не проценты как написано в комменте а доли (нет деления на 100)
А если их название не полностью отражает того, что они делают?
Почему длинное название функции для вас абсурдно?
Информационные системы — это моделирование. Модель это нечто, что отвечает на вопросе о некотором аспекте реального мира вместо реального мира. Информационная система должна отвечать на вопрос "какое имя абонента" вместо того чтобы каждый раз спрашивать у абонента. Именно поэтому как только мы немножко пошевелил ваш пример про телефонную книжку, чтобы сделать его более реальным оттуда вылез абонент. Неважно будет это отношение или класс — человеку удобно думать в в этих терминах. Просто у каждой среды моделирования есть свои ограничения.
Насколько мне известно, это далеко не всегда так
Если я сделаю фреймворк, который не откажется, почему его нельзя будет назвать ORM?