Два программиста говорят о том, какую библиотеку выбрать для логгирования, третий это слышит, подключается и советует им что-то по своему опыту, например.
Это зависит от, того, что считать моком и как он реализован. В статически типизированном языке можно динамически генерить моки а волшебство зафигачит Not Implemented Exception, например, во все методы кроме явно указанных.
Если вы для 3х методов класса тесты пишете, а для 4го, который, например, всего лишь однострочная обертка библиотечной функции — нет, то используете ли вы для разработки TDD?
Да. Если я использовал для гвоздя молоток, а для шурупа отвертку, то я использую молоток.
А если вы именно по принципам TDD которые описывают его применимость определили что для этого метода тесты не нужны, то использовали ли вы его для разработки?
А вот тут я бы хотел ссылочку. Я слышал принцип "Тестировать надо то, что может сломаться". В моем представлении тестировать надо то, тестирование чего окупается (легко тестировать или выигрыш от предотвращения багов и влияния на дизайн большой).
Если у вас обычный сеттер без логики — вы пишете сеттер безо всяких тестов.
В моем предcтавлении в классическом TDD не пишут код, пока не упал тест. То есть сеттер я не могу написать без упавшего теста.
Но обычно сеттер нужен не для того, чтобы установить какое-то значение и радоваться этому. А чтобы это как-то повлияло на поведение.
Т.е. я пишу тест "если превышена максимальная глубина стека то выдается эксепшн" а не "если я задаю максимальную глубину стека, то она задана"
потому что все равно нужно покрывать юнит-тестами то, что обычно не надо покрывать, например сеттеры.
Мне кажется из TDD этого не следует. Т.е. сеттеры обычно покрываются в любом случае но не специально предназначенными для этого тестами. Что с TDD что без него.
Централизованое хранилище с возможностью строить запросы
Не требует изменения кода
Есть возможность приоритезации, описания трудоемкости, разные состояния и т.д.
Готовые инструменты визуализации в виде графиков и досок
Мой выбор:
TODO для локальный проблем текущего фичабагабранча/глючных прототипов
TODO для неочевидных мест которые зависят об багов (с указанием конкетного бага, и с указанием в баге конкретного места с TODO которое надо потом почистить)
ничего — для очевидного инженерного долга (если это будет проблемой, кто-то следующий почистит, когда это станет возможно)
я нисколько не сомневаюсь что где-то там в прекрасном мире
И прочие розовые единороги.
Вот тут я не понимаю что именно вы хотите сказать — то, что такого не бывает, или у вас есть какие-то особенности, по которым именно у вас этого не будет?
возможно технология эта в большинстве случаев просто не работает
Лично меня обычно интересует, работает ли это в моем случае, а не в большинстве (достаточно ли у меня интеллекта, чтобы отличить от подделки, сделать самому или выбрать готовое). Возможно в большинстве случаев то, что люди называют словом "лекарство" не работает — меня интересует могу ли я отличить лекарства которые работают от тех, которые не работают.
Есть наниматели которые позволяют писать тексты, соглашаются с оценками команды и т.д. возможно вы с ними просто не сталкивались. Если вы сами понимаете что тесты нужны почему вы отказываете в этом другим людям?
Обычно в таком случае много багов. Баг дошедший до продакшена стоит сравнительно дорого. Если менеджеру это важно то можно ему показать мере принятые в вашей команде процедуры обратной связи
Коммент относится к формуле но остальные части очевидны. Комментарий необходим только части формулы которая относится к компенсации накладных расходов операций с наличностью. Константа имеет единственное предназначение — для использованияв в этой компенсации. Поэтому я предложил назвать ее попонятней — из ее названия модно вывести назначение куска формулы. Ещё можно вывести этот кусок формулы в функцию с говорящим именем.
Так я сейчас не говорю что надо полностью избавляться. Коммент в данном случае скрыл плохое наименование переменной / константы. Имхо достаточно ее переименовать и, может быть, прокомментировать только ее (если она уже не документирована как-то — например, в месте где она вводится, в тесте или типа того).
Тут есть нескоро моментов. Если получится копия реализации, значит пытались назвать функцию не по тому "что" она делает а по тому "как" она эта делает — если по размышлении не получается выделить "что" то можно посмотреть вариант просто заинлайнить (getCustomers().OrderBy(x => x.BirthDay) для меня читаемее чем getCustomers и не сильно отличается чем getCustomersOrderedByBirthDay. Очень длинное отражающее назначение название часто сигнал что необходим рефакторинг.
https://www.scrumalliance.org/get-certified/developer-track/certified-scrum-developer
Два программиста говорят о том, какую библиотеку выбрать для логгирования, третий это слышит, подключается и советует им что-то по своему опыту, например.
Это зависит от, того, что считать моком и как он реализован. В статически типизированном языке можно динамически генерить моки а волшебство зафигачит Not Implemented Exception, например, во все методы кроме явно указанных.
https://habr.com/ru/post/150859/
Пусть это будет не сервис, а просто функция или метод для заказа пиццы?
Да. Если я использовал для гвоздя молоток, а для шурупа отвертку, то я использую молоток.
А вот тут я бы хотел ссылочку. Я слышал принцип "Тестировать надо то, что может сломаться". В моем представлении тестировать надо то, тестирование чего окупается (легко тестировать или выигрыш от предотвращения багов и влияния на дизайн большой).
С моей точки зрения, если для чего-то не пишутся тесты, то для разработки этого не используется TDD.
В моем предcтавлении в классическом TDD не пишут код, пока не упал тест. То есть сеттер я не могу написать без упавшего теста.
Но обычно сеттер нужен не для того, чтобы установить какое-то значение и радоваться этому. А чтобы это как-то повлияло на поведение.
Т.е. я пишу тест "если превышена максимальная глубина стека то выдается эксепшн" а не "если я задаю максимальную глубину стека, то она задана"
Мне кажется из TDD этого не следует. Т.е. сеттеры обычно покрываются в любом случае но не специально предназначенными для этого тестами. Что с TDD что без него.
Расстроенный депрессивный майор?
Или, например, зеркало для распознавание вампиров
Таск в багтрекере
Мой выбор:
Вот тут я не понимаю что именно вы хотите сказать — то, что такого не бывает, или у вас есть какие-то особенности, по которым именно у вас этого не будет?
Лично меня обычно интересует, работает ли это в моем случае, а не в большинстве (достаточно ли у меня интеллекта, чтобы отличить от подделки, сделать самому или выбрать готовое). Возможно в большинстве случаев то, что люди называют словом "лекарство" не работает — меня интересует могу ли я отличить лекарства которые работают от тех, которые не работают.
Есть наниматели которые позволяют писать тексты, соглашаются с оценками команды и т.д. возможно вы с ними просто не сталкивались. Если вы сами понимаете что тесты нужны почему вы отказываете в этом другим людям?
Обычно в таком случае много багов. Баг дошедший до продакшена стоит сравнительно дорого. Если менеджеру это важно то можно ему показать мере принятые в вашей команде процедуры обратной связи
А сколько аджайлов разных вы видели? Были это снговые или западные компании?
Коммент относится к формуле но остальные части очевидны. Комментарий необходим только части формулы которая относится к компенсации накладных расходов операций с наличностью. Константа имеет единственное предназначение — для использованияв в этой компенсации. Поэтому я предложил назвать ее попонятней — из ее названия модно вывести назначение куска формулы. Ещё можно вывести этот кусок формулы в функцию с говорящим именем.
Так я сейчас не говорю что надо полностью избавляться. Коммент в данном случае скрыл плохое наименование переменной / константы. Имхо достаточно ее переименовать и, может быть, прокомментировать только ее (если она уже не документирована как-то — например, в месте где она вводится, в тесте или типа того).
Возможно, дополнить документированием константы. Все кроме нее предназначения уже выражено кодом. Например, то, со она применяется к наличным
Тут есть нескоро моментов. Если получится копия реализации, значит пытались назвать функцию не по тому "что" она делает а по тому "как" она эта делает — если по размышлении не получается выделить "что" то можно посмотреть вариант просто заинлайнить (getCustomers().OrderBy(x => x.BirthDay) для меня читаемее чем getCustomers и не сильно отличается чем getCustomersOrderedByBirthDay. Очень длинное отражающее назначение название часто сигнал что необходим рефакторинг.
CacheOperationsCostCompensation?