ApeCoder ApeCoder

Есть ли еще варианты? Можно ли придумать какой-то другой принцип называть что-то "тестированием X", который одновременно будет позволять использовать не только X при этом не называть E2E тест модульным?

А из чего следует, что если заваливается тест Т при при испорченном X то это является тестом X?

Например, при покупке лампочки в магазине вы говорите "можно я проверю лампочку?", а не "можно я проверю, лампочку, цолоколь, провода, подстанцию, электростанцию и водохранилище"?

Тогда что такое "тестировать X". Верно ли что если что-то тестирует X он должен выполнять только X?

По какому именно определению? Насколько я понял, в прошлый раз мы пришли к выводу что юнит тестов в вашем понимании вообще не бывает, так как никто не мокает класс string.

Ну да, я про это же. Уточнения:
Там не про порядок, а про количество — чем выше к вершине пирамиды тем меньше тестов.

А общение с компонентами через websockets это какие тесты — unit, интеграционные, rкомпонентные, end-to-end или еще какие?

Обычно рекомендуют тестовую пирамиду

Так никто не говорит, что это помогает всем и всегда. Это просто один из способов разделения сообщений по срочности, как мессенджер и почта. Кому-то помогает, кому-то нет.

Я обычно в таком случае открываю тикет скриншарю его и дописываю туда то, что говорят потом спрашиваю правильно ли я написал. Таким образом остаётся согласованная запись принятых решений

В почте уже есть обычно способ классификации писем по важности. Может быть, можно настроить почтового клиента, чтобы уведомления показал только на важные письма?

Статьи, книжки, теоремы и саги уже написаны :) осталось их нагуглить

Это результат прогиба И контракта с фиксированной ценой.

Я слышал, что это временно:

Примечание: В будущем планируется позволить WebAssembly напрямую вызывать Web API.

Платить каждый раз?

По факту все выбирают платить и поддерживать совместимость. Если ваш подход даст мегапреимущество, это всех завоюет. Но он не дает. Рантаймы и нативные приложения есть и известны, он не вытесняют веб

Лучше вы расскажите — это ж у вас принят "массаж напряженным членом" а у нас и фронт и бек — разработчики.

Не для всех видов массажа необходим хороший массажист, насколько я знаю. Некоторые виды массажа непрофессиональные люди волне успешно делают друг другу.

Бекэнд может помочь фронтенду, например, со вспомогательными — развертывание сред, воспроизведение багов, тестирование и т.д.

зато в следующем будет готово больше чем обычно.

Да, если объем работы для Бека и фронта в среднем статистически соответствует их возможностям. То есть команда сбалансирована. Иначе будет просто накопление wip

А ещё есть куча не продуктовых задач, которые тоже надо делать.

Это да

Боюсь даже спрашивать какая чёрная магия позволила вам сделать такой вывод.

"Сбалансировать" — достигнуть наилучшего соотношения фронта и бека для решения поставленных задач. Если нельзя достигнуть наилучшего соотношения, то все соотношения одинаковы — в том числе один бек.

Но если вам нужно решение, то оно простое — отдельно оценивать и набирать в спринт задачи по каждой специализации.

Т.е. результатом спринта может быть что-то неготовое к использованию, например, сделан один бек без фронта?

То есть любое соотношение бека и фронта эквивалентно? Можно оставить один бек и решать все задачи?

Чтобы сформулировать идею, каким образом в отличие от других компании собираются заработать денег.

Google: Цель компании Google – упорядочить всю информацию в мире и сделать ее доступной каждому

Amazon: Our vision is to be Earth's most customer centric company; to build a place where people can come to find and discover anything they might want to buy online.

...

Киоск с шаурмой: Мы накормим Южное Бутово самой дешевой шаурмой с картошкой

Разумеется, если вы еще не заметили, то люди из всего делают карго культ.

Насколько я понял, чтобы дроп что-то делал он должен еще не сидеть. Если их регулярно сажать, по идее предложение дропов может уменьшиться и цена возрасти

• счет (на который вам бы предложили перевести деньги) — на подставное лицо, на потерянный паспорт или на дропа

А нельзя сделать больно дропу чтобы они были дороже?

Кстати, решение "те, кто освободились, помогают тем кто работает" делает потихонечку всех T-shaped

И тут появляется только что закончивший читать Scrum and XP from the Trenches PM и говорит

Если я правильно понимаю, что написано в книжке и вашу ситуацию, то увеличить количество сторипоинтов на следующую итерацию это против книжки потому, что считаются только готовые истории, а те, в которых сделан только бекенд не считаются.

А что, если история была почти закончена? Почему мы не используем дробные значения для таких
историй при подсчете реальной производительности? Потому, что Scrum (как и гибкая разработка (agile), да и
бережливое производство (lean)) ориентирован на то, чтобы создавать законченный, готовый к поставке
продукт! Ценность реализованной наполовину истории нулевая (а то и отрицательная). См. книгу “Managing
the Design Factory” автора Donald Reinertsen или одну из книг авторов Mary Poppendieck и Tom Poppendieck.

С моей точки зрения в духе книжки было бы попросить бекенд помочь фронтенду на простых или вспомогательных задачах — ситуация аналогична главе Чем занимается тестировщик, когда нечего тестировать. Либо устранением технического долга — внутренними вещами — если они совсем ничем не могут помочь спринту.

Интересно было бы сравнить с .NET Core 3.0 и System.Text.JSON. По ссылкам обещают ускорение:

Description  RPS    CPU (%) Memory (MB)
Newtonsoft.Json – 500 B 136,435 95  172
System.Text.Json – 500 B    167,861 94  169
Newtonsoft.Json – 2.4 KB    97,137  97  174
System.Text.Json – 2.4 KB   132,026 96  169
Newtonsoft.Json – 40 KB 7,712   88  212
System.Text.Json – 40 KB    16,625  96  193

Вы когда-нибудь встречали скрам-инженера?

https://www.scrumalliance.org/get-certified/developer-track/certified-scrum-developer

Два программиста говорят о том, какую библиотеку выбрать для логгирования, третий это слышит, подключается и советует им что-то по своему опыту, например.

Это зависит от, того, что считать моком и как он реализован. В статически типизированном языке можно динамически генерить моки а волшебство зафигачит Not Implemented Exception, например, во все методы кроме явно указанных.

https://habr.com/ru/post/150859/

Пусть это будет не сервис, а просто функция или метод для заказа пиццы?

Если вы для 3х методов класса тесты пишете, а для 4го, который, например, всего лишь однострочная обертка библиотечной функции — нет, то используете ли вы для разработки TDD?

Да. Если я использовал для гвоздя молоток, а для шурупа отвертку, то я использую молоток.

А если вы именно по принципам TDD которые описывают его применимость определили что для этого метода тесты не нужны, то использовали ли вы его для разработки?

А вот тут я бы хотел ссылочку. Я слышал принцип "Тестировать надо то, что может сломаться". В моем представлении тестировать надо то, тестирование чего окупается (легко тестировать или выигрыш от предотвращения багов и влияния на дизайн большой).

С моей точки зрения, если для чего-то не пишутся тесты, то для разработки этого не используется TDD.

Если у вас обычный сеттер без логики — вы пишете сеттер безо всяких тестов.

В моем предcтавлении в классическом TDD не пишут код, пока не упал тест. То есть сеттер я не могу написать без упавшего теста.
Но обычно сеттер нужен не для того, чтобы установить какое-то значение и радоваться этому. А чтобы это как-то повлияло на поведение.

Т.е. я пишу тест "если превышена максимальная глубина стека то выдается эксепшн" а не "если я задаю максимальную глубину стека, то она задана"

потому что все равно нужно покрывать юнит-тестами то, что обычно не надо покрывать, например сеттеры.

Мне кажется из TDD этого не следует. Т.е. сеттеры обычно покрываются в любом случае но не специально предназначенными для этого тестами. Что с TDD что без него.

Расстроенный депрессивный майор?

давая отражения только кошек (но не собак)

Или, например, зеркало для распознавание вампиров

• Быстро завести
• Точная привязка к коду

• Централизованое хранилище с возможностью строить запросы
• Не требует изменения кода
• Есть возможность приоритезации, описания трудоемкости, разные состояния и т.д.
• Готовые инструменты визуализации в виде графиков и досок

Мой выбор:

• TODO для локальный проблем текущего фичабагабранча/глючных прототипов
• TODO для неочевидных мест которые зависят об багов (с указанием конкетного бага, и с указанием в баге конкретного места с TODO которое надо потом почистить)
• ничего — для очевидного инженерного долга (если это будет проблемой, кто-то следующий почистит, когда это станет возможно)
• для остального — багтрекер

я нисколько не сомневаюсь что где-то там в прекрасном мире
И прочие розовые единороги.

Вот тут я не понимаю что именно вы хотите сказать — то, что такого не бывает, или у вас есть какие-то особенности, по которым именно у вас этого не будет?

возможно технология эта в большинстве случаев просто не работает

Лично меня обычно интересует, работает ли это в моем случае, а не в большинстве (достаточно ли у меня интеллекта, чтобы отличить от подделки, сделать самому или выбрать готовое). Возможно в большинстве случаев то, что люди называют словом "лекарство" не работает — меня интересует могу ли я отличить лекарства которые работают от тех, которые не работают.

Есть наниматели которые позволяют писать тексты, соглашаются с оценками команды и т.д. возможно вы с ними просто не сталкивались. Если вы сами понимаете что тесты нужны почему вы отказываете в этом другим людям?

Обычно в таком случае много багов. Баг дошедший до продакшена стоит сравнительно дорого. Если менеджеру это важно то можно ему показать мере принятые в вашей команде процедуры обратной связи

А сколько аджайлов разных вы видели? Были это снговые или западные компании?