Здравствуйте, varenikAA, Вы писали:
AA>Тестирование лишь способ автоматизировать выполнение написанного кода. AA>Использовать его в качестве метода разработки бесполезно и даже вредно.
А ещё из той же серии, писать повторно используемый код тоже вредно, потому что на него тратится в несколько раз больше усилий чтобы проверить несколько различных случаев его использования. Вот и вопрос, писать ли тесты, писать ли повторно используемый код и так далее. Однозначного ответа здесь естественно нет, зависит от множества факторов одним из которых является сам программист.
V>А ещё из той же серии, писать повторно используемый код тоже вредно, потому что на него тратится в несколько раз больше усилий чтобы проверить несколько различных случаев его использования. Вот и вопрос, писать ли тесты, писать ли повторно используемый код и так далее. Однозначного ответа здесь естественно нет, зависит от множества факторов одним из которых является сам программист.
Код не придётся использовать повторно, если каждый раз достаточно быстро увольняться и устраиваться в другое место с большей зарплатой.
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
Здравствуйте, Osaka, Вы писали:
O>Код не придётся использовать повторно, если каждый раз достаточно быстро увольняться и устраиваться в другое место с большей зарплатой.
Т.е повторное использование программиста тоже исключаем для снижения общей вредности?
Здравствуйте, netch80, Вы писали:
AA>>Использовать его в качестве метода разработки бесполезно и даже вредно.
N>Докажите.
Это очевидно, сначала нужен тестируемый объект.
это как поставить телегу впереди лошади.
Возvожно в каких-то ЯП из-за их слабости этот метод бы и подошел, но я думаю все же лучше сразу проектировать рабочий компонент.
а при помощи тестирования лишь проверять качество(привет, Property-based testing).
Здравствуйте, varenikAA, Вы писали:
AA>>>Использовать его в качестве метода разработки бесполезно и даже вредно.
N>>Докажите.
AA>Это очевидно, сначала нужен тестируемый объект.
С какого "начала"?
AA>это как поставить телегу впереди лошади.
Какую телегу и впереди какой лошади? Прошу выражаться ясно и без сомнительных аналогий.
AA>Возvожно в каких-то ЯП из-за их слабости этот метод бы и подошел, но я думаю все же лучше сразу проектировать рабочий компонент.
"Лучше быть богатым и здоровым, чем бедным и больным" (tm)
Да, лучше сразу проектировать рабочий компонент. Только вот проблема — не получается.
AA>а при помощи тестирования лишь проверять качество(привет, Property-based testing).
У меня возникло подозрение, что вы на самом деле говорите не про тестирование в общем, а про test-driven development.
Если так, то я согласен, что в чистом виде эта методология не годится ни для чего, кроме одноразового кода, написанного с нуля. Любое её реальное применение так или иначе нарушает какие-то её каноны.
Но ни в коем случае нельзя такого говорить про тестирование вообще, потому что оно является почти единственным способом _показать_ с управляемой достоверностью, что задание понято и реализовано правильно.
Здравствуйте, varenikAA, Вы писали:
N>>Докажите.
AA>Это очевидно, сначала нужен тестируемый объект.
Не нужен.
AA>Возvожно в каких-то ЯП из-за их слабости этот метод бы и подошел, но я думаю все же лучше сразу проектировать рабочий компонент.
Лучше и писать сразу без ошибок.
Рабочий вариант как правило на старте неизвестен. Если у тебя не так, это значит, ты занимаешься задачами, которые уже перерос.
AA>а при помощи тестирования лишь проверять качество(привет, Property-based testing).
А как ты качество понимаешь, раз оно у тебя в проектировании отсутствует?
Вот твой property-based
const fc = require('fast-check');
fc.assert(
fc.property(
fc.string(), fc.string(), fc.string(),
(a, b, c) => contains(b, a+b+c))
);
кто тебе мешает написать такой код еще до того, как concat объявлена?
Здравствуйте, Ikemefula, Вы писали:
I>Вот твой property-based I>
I>const fc = require('fast-check');
I>fc.assert(
I> fc.property(
I> fc.string(), fc.string(), fc.string(),
I> (a, b, c) => contains(b, a+b+c))
I>);
I>
I>кто тебе мешает написать такой код еще до того, как contains объявлена?
Потому что это пустая трата времени.
потом придется все это продублировать в рабочем коде.
и вы не просто потеряете время, но и вполне вероятно "не увидите леса за деревьями".
Здравствуйте, velkin, Вы писали:
AA>>Тестирование лишь способ автоматизировать выполнение написанного кода. AA>>Использовать его в качестве метода разработки бесполезно и даже вредно.
V>А ещё из той же серии, писать повторно используемый код тоже вредно, потому что на него тратится в несколько раз больше усилий чтобы проверить несколько различных случаев его использования. Вот и вопрос, писать ли тесты, писать ли повторно используемый код и так далее. Однозначного ответа здесь естественно нет, зависит от множества факторов одним из которых является сам программист.
Писать код вообще вредно, не только для программиста но и для заказчика. Им обоим самом деле это всё не нужно. Это отдаляет от природы, от деревни, от общины.
Здравствуйте, varenikAA, Вы писали:
AA>>>Это очевидно, сначала нужен тестируемый объект.
N>>С какого "начала"?
AA>разработка через тестирования начинается с написания тестов, когда тестировать нечего, если вы делаете так, то это очень странно.
А, то есть таки речь про TDD, а не про тестирование в целом, я угадал.
Рекомендую тогда исправить заголовок: сейчас он неадекватен.
Про TDD хочу сказать, что в частных случаях это очень полезная и удобная методика, когда или есть твёрдая уверенность в требуемой функциональности, или когда удобно делать преодоление
Здравствуйте, varenikAA, Вы писали:
AA>Потому что это пустая трата времени. AA>потом придется все это продублировать в рабочем коде.
Что именно "всё это" "придётся продублировать"?
Вот у меня новая суперсортировка. Я пишу тест: sort([3,2,5,4,1]) == [1,2,3,4,5]. Это дублирование кода сортировки или нет?
Вот contains, как у Ikemefula. Сделан на алгоритме Бойера-мура (там, где табличка минимальных смещений для символа). Где дублирование кода?
AA>и вы не просто потеряете время, но и вполне вероятно "не увидите леса за деревьями".
Чтобы видеть лес, тесты добавляются (или просто активируются, снимая пометку #[NotYet]) постепенно.
Здравствуйте, netch80, Вы писали:
N>Вот у меня новая суперсортировка. Я пишу тест: sort([3,2,5,4,1]) == [1,2,3,4,5]. Это дублирование кода сортировки или нет?
на момент написания тест sort уже существует? тогда ок, проверяется рабочий код.
Здравствуйте, varenikAA, Вы писали:
I>>Тестирование это проверка соответствия результата требованиям.
AA>И в проде не случалось ни разу ошибки после вашего тестирования?
не существует методики ни разработки, ни тестирования, которая может дать гарантию отсутствия ошибок
Качество это всего лишь степень соответствия требованиям, которая вобщем есть вероятность в зависимости от следующих вещей
1. качество самих требований, упс, рекурсия!
2. методика испытаний и процесс тестирования
3. технологии разработки
4. подход к проектированию
5. квалификация команды
6. процесс разработки
Точно так же и в security не сущетсвует способа дать гарантию отсутствия любых уязвимостей.
Собственно, это не повод отказываться от тестирования, т.к. именно здесь мы убеждаемся, что
1. методы а и б работают на предложенном множестве данных.
2. компоненты обладают нужным поведением
3. модуль, пакет предоставляют нужные функциональные возможности
4. приложение умеет нужные функции, см перечень
5. приложение покрывает все известные сценарии, см перечень сценариев
6. приложение покрывает все критические кейсы, см перечень кейсов
Здравствуйте, varenikAA, Вы писали:
I>>кто тебе мешает написать такой код еще до того, как contains объявлена?
AA>Потому что это пустая трата времени. AA>потом придется все это продублировать в рабочем коде.
Не надо ничего дублировать! Следующий шаг — a+b+c надо выделить в отдельную функцию. И нет никакого дублирования
AA>и вы не просто потеряете время, но и вполне вероятно "не увидите леса за деревьями".
Наоборот, изначально нужно представлять чего ты хочешь добиться. Вот эти ожидания и фиксируются тестами.
Например, в моем примере ожидание вполне понятное — свойство самого concat
Вначале пишем тест для свойства, а потом выделяем уже реализацию.
На самом деле в ТДД непринципиально когда именно ты пишешь тест, до или после.
Часть задач лучше решается, если писать тесты до, часть задачь — если тесты после.
