Здравствуйте, Nuzhny, Вы писали:
N>И тут должен следовать пример, подтверждающий правоту твоих слов.
Примером не доказывают. Нужно обобщённое обоснование. Оно выше, про условно бесконечное время, нужное для написани тестов, которые бы покрывали всё в случае сложной системы. А частичное покрытие-это те самые деревья, за которыми не видно леса, о чём упоминал TC.
Здравствуйте, smeeld, Вы писали:
S>Примером не доказывают.
Вообще-то доказывают. Теоремы о существовании в математике доказывают как раз примерами существования искомых объектов. Это называется доказательством с помощью построения или конструктивным доказательством.
S>Нужно обобщённое обоснование. Оно выше, про условно бесконечное время, нужное для написани тестов, которые бы покрывали всё в случае сложной системы. А частичное покрытие-это те самые деревья, за которыми не видно леса, о чём упоминал TC.
Не надо покрывать все случаи жизни, надо лишь покрыть формальные требования, а также крайние случаи. Сложная система совсем без тестов бесполезна.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, smeeld, Вы писали:
S>>Примером не доказывают.
N>Вообще-то доказывают. Теоремы о существовании в математике доказывают как раз примерами существования искомых объектов. Это называется доказательством с помощью построения или конструктивным доказательством.
Ты когда последний раз математику открывал?
N>Не надо покрывать все случаи жизни, надо лишь покрыть формальные требования, а также крайние случаи. Сложная система совсем без тестов бесполезна.
Ясно, разраб хеллоуворлдов, или очередной ыффективный аркитектор.
Здравствуйте, varenikAA, Вы писали:
AA>Тестирование лишь способ автоматизировать выполнение написанного кода. AA>Использовать его в качестве метода разработки бесполезно и даже вредно.
Не понятно, что понимается под "использование тестирования в качестве метода разработки".
В любом случае без тестов очень трудно поддерживать систему.
Рефакторинг затруднен, добавление фич затруднено. С тестами намного удобнее/спокойнее.
Здравствуйте, smeeld, Вы писали:
S>Ты когда последний раз математику открывал?
То есть опять голословие и незнание понятие "конструктивное доказательство" в математике.
N>>Не надо покрывать все случаи жизни, надо лишь покрыть формальные требования, а также крайние случаи. Сложная система совсем без тестов бесполезна. S>Ясно, разраб хеллоуворлдов, или очередной ыффективный аркитектор.
I>Разрабатываешь ты не абы как, а именно для достижения конкретного результата. А раз так, то надо всегда проверять, достигаешь ли ты его. I>И вот эта проверка и есть тестирование.
И как в этом убедиться не написав тест для теста?
S>Иссследовательские разработки хеллуоворлдов. Потому-что на что посерьёзней тестов не непишешься, на это уйдёт время равное времени существования вселенной. Только если на какие-то самые базовые вещи.
Совершенно верно. Если посадить писать тесты дураков.
Тестировать базовый функционал на уровне юнитов требует линейного количество тестов.
Но поскольку дураки в тесты не умеют, они будут сначала ждать, пока не накопится тестируемый функционал и попытаются тестировать систему в целом. И очень быстро обнаруживают, что число тестов растет экспоненциально от числа юнитов, составляющих систему.
S>А неумение реализовать базовый функционал без тестов-это неумение разрабатывать, aka криворукость.
AA>Очевидно же с самого начала, тестирование бесполезно для РАЗРАБОТКИ.
Лучше смотреть английскую версию
Software development is the process of conceiving, specifying, designing, programming, documenting, testing, and bug fixing involved in creating and maintaining applications, frameworks, or other software component
То есть, к разработке относится и программирование, и документация, и проектирование, и багфикс, и мейнтенанс.
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, netch80, Вы писали:
N>>А если ещё не существует — задаётся требование к результату функции (его проекция в виде конкретного тесткейса). N>>Почему этого нельзя сделать?
AA>Можно, но зачем? вы пишете тесты или программу?
Написание программы невозможно без хотя бы неформального оформления требований к программному компоненту.
Критической частью функциональности тестов является выражение и проверка этих требований.
Формализация этих требований на языке программирования является частью работы программиста (даже если он будет называться "автоматизированным тестировщиком" или как-то похоже).
AA>Есть такая профессия тестировщик.
Не вижу тут смысла ни в прямой, ни в обратной аналогии с телегой и лошадью.
Скорее это две лошади разного характера в одной телеге.
Зато известно, что баг, отловленный программистом до прихода к отдельным тестерам, обходится (обычно) в разы дешевле, чем пойманный уже этими тестерами.
Здравствуйте, smeeld, Вы писали:
N>>Вообще-то исследовательские разработки ведутся как раз наоборот: сначала тесты, а потом код.
S>Иссследовательские разработки хеллуоворлдов.
Наоборот. в серьезных проектах сначала прорабатываются требования. Между стартом проекта и стартом разработки бывают проходят месяцы-годы. И нормой является смена подхода.
Б>В любом случае без тестов очень трудно поддерживать систему.
Мотря какая система и мотря какие тесты.
Б>Рефакторинг затруднен, добавление фич затруднено. С тестами намного удобнее/спокойнее.
При богомерзких микросервисах в "облаках" это совсем не удобно. И вообще не добавляет спокойства. Упасть может буквально всё и в любой момент времени. И по любой причине.
Здравствуйте, Poopy Joe, Вы писали:
I>>Разрабатываешь ты не абы как, а именно для достижения конкретного результата. А раз так, то надо всегда проверять, достигаешь ли ты его. I>>И вот эта проверка и есть тестирование. PJ>И как в этом убедиться не написав тест для теста?
Точно так же, как проверяем, пользуется ли разработчик головой или нет.
Задача "сторожить сторожа" возникает во всех областях, где необходим контроль хоть чего нибудь.
0 пишем внятные требования к качеству тестов и проверяем, соблюдаетсли ли оно
1 методики, подходы
2 подготовка персонала
3 аудит
4 ревью
5 инструменты
6 иногда таки пишется тест для теста
Здравствуйте, Ватакуси, Вы писали:
Б>>Рефакторинг затруднен, добавление фич затруднено. С тестами намного удобнее/спокойнее. В>При богомерзких микросервисах в "облаках" это совсем не удобно. И вообще не добавляет спокойства. Упасть может буквально всё и в любой момент времени. И по любой причине.
Может. Это не повод отказываться от тестов. Если убрать юнит-тесты, то простое переименование переменной становится причиной еще большего хаоса.
I>Может. Это не повод отказываться от тестов. Если убрать юнит-тесты, то простое переименование переменной становится причиной еще большего хаоса.
Для этого есть компиляторы или хотя бы стат. анализаторы.
Я вот сейчас работаю с проектом, где до одного места этих микросервисов, которые ещё засунуты в самописный велосипед. 80% тестов ничего не тестируют, а просто добавляют "покрытие".
Там тупо всё mocked.
Здравствуйте, Ватакуси, Вы писали:
В>Для этого есть компиляторы или хотя бы стат. анализаторы.
Ага, есть
В>Я вот сейчас работаю с проектом, где до одного места этих микросервисов, которые ещё засунуты в самописный велосипед. 80% тестов ничего не тестируют, а просто добавляют "покрытие". В>Там тупо всё mocked.
Здравствуйте, Ikemefula, Вы писали:
PJ>>И как в этом убедиться не написав тест для теста?
I>Точно так же, как проверяем, пользуется ли разработчик головой или нет. I>Задача "сторожить сторожа" возникает во всех областях, где необходим контроль хоть чего нибудь. I>0 пишем внятные требования к качеству тестов и проверяем, соблюдаетсли ли оно I>1 методики, подходы I>2 подготовка персонала I>3 аудит I>4 ревью I>5 инструменты I>6 иногда таки пишется тест для теста
Почему нельзя воспользоваться требованиями, методиками, подходами и далее по списку, в отношении решения, а не теста? Этого либо достаточно, либо еще нужен тест для теста для теста...
Здравствуйте, smeeld, Вы писали:
N>>Вообще-то доказывают. Теоремы о существовании в математике доказывают как раз примерами существования искомых объектов. Это называется доказательством с помощью построения или конструктивным доказательством. S>Ты когда последний раз математику открывал?
Человек занимается CV (машинным зрением), Вы хоть один алгоритм из этой области знаете или видели, чтобы про
математику спрашивать? Я не про базовые вещи говорю, а, например, про детекцию чего-либо на фото.
Здравствуйте, Ватакуси, Вы писали:
В>Я вот сейчас работаю с проектом, где до одного места этих микросервисов, которые ещё засунуты в самописный велосипед. 80% тестов ничего не тестируют, а просто добавляют "покрытие". В>Там тупо всё mocked.
Все правильно, это юнит-тесты, тестирующие модуль изолированно. Для совместного теста надо писать интеграционные тесты.
В>>Я вот сейчас работаю с проектом, где до одного места этих микросервисов, которые ещё засунуты в самописный велосипед. 80% тестов ничего не тестируют, а просто добавляют "покрытие". В>>Там тупо всё mocked.
S>Все правильно, это юнит-тесты, тестирующие модуль изолированно. Для совместного теста надо писать интеграционные тесты.
Нет, там вообще ВСЁ mocked
Т.е. тест выгляди так
Mock everything
Call something
Check something called something 1, something 2, etc.
