Хотелось бы спросить автора и его дядюшку, почему они уверены, что их тесты корректны?
При TDD тест частично тестируется тем что он падает при отсутствии реализации. Вообще речь не идет о какой-то абсолютной корректности. Все те же самые вопросы можно задать и по поводу ручного тестирования.
И кто тогда будет писать тесты, тестирующие тесты? А тесты, тестирующие тесты, тестирующие тесты? Ну и так далее.
Кто тестирует тех кто тестирует вручную?
Как тестировать приватные методы?
Вызовом публичных?
А методы с побочными эффектами?
Проверкой на наличие побочных эффектов?
Я пытался узнать у тех, кто не испытывает неприязни к ТДД, и получил ответ, что никак.
Про тесты написаны кучи книжек — попробуйте почитать хотя бы одну.
Какой тогда в этом смысл? Большая часть функционала обычно бывает скрыта, и тестировать публичные методы, предполагая, что приватные выдадут корректный результат, как-то несерьезно.
Если у большая часть функционала скрыта, это значит что у вас god object или подобный антипаттерн. Надо рефакторить — разделять уровни абстракции и их тестировать отдельно.
Получается, что покрытие тестами будет достигать в лучшем случае процентов тридцать (чаще намного меньше).
А как вы тестируете вручную — не покрываете приватные методы?
Думаю, что я могу ответить на вопрос, почему эта методология не получила широкого признания. Потому что она бессмысленна. Люди не хотят тратить свое время на то, что заведомо не сработает или даст мизерный выхлоп.
Люди не хотят тратить время на то, чтобы хотя бы погуглить
Потому что нету никакой альтернативной формулировки. Сперва вы выясняете, что вам нужны прямые углы, а потом уже подбираете фигуру, с этими углами. Не наоборот.
Конечно, не обязательно. Но к чему вы это?
К тому, что вы можете понять, что у нас с вами примерно одинаковые точки зрения.
То есть вы даже не можете сопоставить два кусочка текста
выше "методология требует X" и "машина требует бензина".
Вы просто не можете понять альтернативную формулировку. Если X требует Y не обязательно выбирать X. Если машина требует бензина, а у вас его нет не обязаетльно добывать бензин, можно поехать на велосипеде. Правда велосипед потребует наличия сильных здоровых ног. А еще надо на нем уметь кататься.
Требует и позволяет не методология, а заказчик. И уже в рамках требований заказчика вы можете выбрать методологию, которая удовлетворит этим требованиям наиболее полно.
Так методология требует тоже — в том смысле в котором определение квадрата требует наличия четырех углов.
Никакая методология вам не поможет выпустить продукт за 3 месяца вместо двух лет. Даже за полгода вместо двух месяцев — не поможет. Даже за 4 вместо 3. Эффективность перевода времени в условные фиче-тугрики — это свойство исключительно вашей команды.
Это может быть не тот же самый продукт. Одна методология требует спроектировать все последовательно до последней запятой, другая позволит выпустить MVP а потом посмотреть как пойдет.
Мне кажется, я могу найти соответствие между спринтом и определениями:
Проект в управленческой деятельности (соответствует англ. project от лат. projectus «брошенный вперёд, выступающий, выдающийся вперёд») — временное предприятие, направленное на создание уникального продукта, услуги или результата (см. PMBOK)[3]:3.
Управление проектами — область деятельности, в ходе которой определяются и достигаются чёткие цели проекта при балансировании между объёмом работ, ресурсами (такими как деньги, труд, материалы, энергия, пространство и другими), временем, качеством и рисками (PMBoK)
Например, тебе из легаси-недр в 2к18 прилетают не джсоны, а xml, при чем, написанные криво на коленке человеком, который всю жизнь курил героин. Это сложная задача? Безусловно, понять логику человека, который создает этих франкенштейнов — непросто. Но разве такие задачи развивают?
Да, развивают — умение рассуждать о коде и данных и извлекать информацию из того, что есть. Есть даже книжка "Working with legacy code"
Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
Книжка Джефа Сазерленда (одного из авторов скрам) так и называется «Scrum: The Art of Doing Twice the Work in Half the Time». Т.е. у самих авторов маркетинговое обещание именно такое — в 4 раза быстрее.
— Послушай, услышь и запомни: я уволю тебя к чертям! – перешел Боб на крик.
Боб, похоже, хамло — перебивает и кричит,.
Боб, похоже, тупой — вместо того, чтобы разобраться в чем причина провала, сразу делает выводы.
И заказчик вроде доволен был.
— Конечно доволен! Потому что до этого он вообще ничего не получал!
То есть у заказчика есть печеньки а до этого не было ничего? Если вернуть как было, от этого будет не ничего, а кусок мяса?
— А как работать? – нахмурился Джон.
— Просто. Нормально. Работать. – чеканя каждое слово, сказал Боб.
Боб, похоже, тупой — эти три слова никак не описывают как работать. У них будет какой-то процесс работы, просто не будет никакого слова, как он называется.
То, что Боб не понимает, что этих слов недостаточно, чтобы описать, что собственно он хочет, еще один признак того, что он тупой.
Мой вывод — Боб, тупое хамло практически неспособное сказать ничего по сути и заменяющее анализ и аргументацию потоком эмоций. Ответственность за организацию работы он на себя брать не хочет.
При чем тут вообще разные кодировки. В С# внутри используется UTF16, все строки в ней. Если строка в другой кодировке — это массив байтов, а не строка. Строка UTF16 может содержать суррогатные пары.
Вам надо либо спроектировать нагрузочный тест чтобы получить "там, где тормозит" либо это будет тратить время людей, которые буду жаловаться на тормоза пока это не исправят.
Если у вас быстрый цикл обратной связи, то хорошо. Если у вас БД на атомной подводной лодке на которую можно накатить патч раз в полгода, то плохо.
Было бы очень интересно послушать от вас цепочку рассуждений.
Ничего волшебного. Просто надо либо запоминать свойства индекса либо вывести их из знания его внутренней структуры. Второе не потребует циклов обратной связи. Например если есть запрос выбирающий по полям соединенных таблиц, то отдельное их индексирование ускорит меньше чем индексирование по паре, соответственно деномализация тут может помочь (и так далее).
Это не UTF8 — это UTF16 (т.е. внутреннее представление С#). Если этого не учитывать, то код будет некорректно работать на некоторых языках. (см surrogate pairs)
Я предлагаю отныне их называть «функции-самозванцы» ибо это короче чем «самовызываемые», так же неправильно и позволяет закольцевать тему в мире метафор.
При TDD тест частично тестируется тем что он падает при отсутствии реализации. Вообще речь не идет о какой-то абсолютной корректности. Все те же самые вопросы можно задать и по поводу ручного тестирования.
Кто тестирует тех кто тестирует вручную?
Вызовом публичных?
Проверкой на наличие побочных эффектов?
Про тесты написаны кучи книжек — попробуйте почитать хотя бы одну.
Если у большая часть функционала скрыта, это значит что у вас god object или подобный антипаттерн. Надо рефакторить — разделять уровни абстракции и их тестировать отдельно.
А как вы тестируете вручную — не покрываете приватные методы?
Люди не хотят тратить время на то, чтобы хотя бы погуглить
See also https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM
Заказчиков с их требованиями тоже можно выбирать под методологию. Как и методологии под заказчиков. Это бизнес решение.
К тому, что вы можете понять, что у нас с вами примерно одинаковые точки зрения.
То есть вы даже не можете сопоставить два кусочка текста
выше "методология требует X" и "машина требует бензина".
Так методология требует тоже — в том смысле в котором определение квадрата требует наличия четырех углов.
Это может быть не тот же самый продукт. Одна методология требует спроектировать все последовательно до последней запятой, другая позволит выпустить MVP а потом посмотреть как пойдет.
Мне кажется, я могу найти соответствие между спринтом и определениями:
Да, развивают — умение рассуждать о коде и данных и извлекать информацию из того, что есть. Есть даже книжка "Working with legacy code"
Тогда они скажут "просто работать is dead"!
Боб, похоже, хамло — перебивает и кричит,.
Боб, похоже, тупой — вместо того, чтобы разобраться в чем причина провала, сразу делает выводы.
То есть у заказчика есть печеньки а до этого не было ничего? Если вернуть как было, от этого будет не ничего, а кусок мяса?
Боб, похоже, тупой — эти три слова никак не описывают как работать. У них будет какой-то процесс работы, просто не будет никакого слова, как он называется.
То, что Боб не понимает, что этих слов недостаточно, чтобы описать, что собственно он хочет, еще один признак того, что он тупой.
Мой вывод — Боб, тупое хамло практически неспособное сказать ничего по сути и заменяющее анализ и аргументацию потоком эмоций. Ответственность за организацию работы он на себя брать не хочет.
В UTF-16 есть суррогатные пары. Почитайте википедию
try.dot.net
> True
Вам надо либо спроектировать нагрузочный тест чтобы получить "там, где тормозит" либо это будет тратить время людей, которые буду жаловаться на тормоза пока это не исправят.
Если у вас быстрый цикл обратной связи, то хорошо. Если у вас БД на атомной подводной лодке на которую можно накатить патч раз в полгода, то плохо.
Ничего волшебного. Просто надо либо запоминать свойства индекса либо вывести их из знания его внутренней структуры. Второе не потребует циклов обратной связи. Например если есть запрос выбирающий по полям соединенных таблиц, то отдельное их индексирование ускорит меньше чем индексирование по паре, соответственно деномализация тут может помочь (и так далее).