Здравствуйте, iZEN, Вы писали:
N>>Вот у меня новая суперсортировка. Я пишу тест: sort([3,2,5,4,1]) == [1,2,3,4,5]. Это дублирование кода сортировки или нет?
ZEN>Это сравнение возвращаемой функцией sort() ссылки на объявленный в коде массив. Чего вы этим хотите добиться?
Вы даже не уточнили, о каком языке идёт речь в этом псевдокоде и какое сравнение участвует, а уже пытаетесь буквоедствовать.
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, netch80, Вы писали:
N>>Вот у меня новая суперсортировка. Я пишу тест: sort([3,2,5,4,1]) == [1,2,3,4,5]. Это дублирование кода сортировки или нет?
AA>на момент написания тест sort уже существует?
Какая разница?
AA> тогда ок, проверяется рабочий код.
А если ещё не существует — задаётся требование к результату функции (его проекция в виде конкретного тесткейса).
Почему этого нельзя сделать?
И вообще вопрос был в другом: откуда предыдущее утверждение про дублирование кода? Вы ушли в сторону.
Здравствуйте, varenikAA, Вы писали:
AA>Тестирование лишь способ автоматизировать выполнение написанного кода.
Да. AA>Использовать его в качестве метода разработки бесполезно и даже вредно.
Нет.
Когда ты пишешь тесты, то тесты являются потребителем тестируемого кода, а следовательно, уже на этапе написания тестов, интерфейсы, структура классов становятся продуманнее, более SOLIDными
Здравствуйте, varenikAA, Вы писали:
AA>разработка через тестирования начинается с написания тестов, когда тестировать нечего, если вы делаете так, то это очень странно.
Очень странно делать заявления космического масштаба без каких-то аргументов.
Разработка через тестирование это работающий подход к разработке со своими плюсами и минусами. Нравится тебе он или нет, это вопрос другой.
Здравствуйте, varenikAA, Вы писали:
AA>Тестирование лишь способ автоматизировать выполнение написанного кода.
Верёвка есть вервие простое, угу.
AA>Использовать его в качестве метода разработки бесполезно и даже вредно.
Ты продолжаешь раз за разом делать одну и ту же ошибку — оценивать профессиональные инструменты с точки зрения человека, который просто балуется с программированием.
Здравствуйте, varenikAA, Вы писали:
AA>Потому что это пустая трата времени. AA>потом придется все это продублировать в рабочем коде. AA>и вы не просто потеряете время, но и вполне вероятно "не увидите леса за деревьями".
Давай я тебе на аналогии проиллюстрирую.
Вот, к примеру, надо тебе построить авто. Ты чертежи сперва нарисуешь, или начнешь на глазок железки пилить, а чертежи потом по факту нарисуешь?
Тесты в случае TDD это формальная спецификация, требование к тому что тебе надо реализовать. Можно, конечно, написать текст и писать по нему код с поправкой на испорченный телефон. А можно написать тест, который невозможно понять не так.
Здравствуйте, varenikAA, Вы писали:
AA>Тестирование лишь способ автоматизировать выполнение написанного кода. AA>Использовать его в качестве метода разработки бесполезно и даже вредно.
Ещё code coverage есть. Вот уж религия, и ради большого code coverage зачастую пишутся фуфловые тесты, которые ничего не тестируют, зато покрывают.
Здравствуйте, netch80, Вы писали:
N>А если ещё не существует — задаётся требование к результату функции (его проекция в виде конкретного тесткейса). N>Почему этого нельзя сделать?
Можно, но зачем? вы пишете тесты или программу?
Есть такая профессия тестировщик. Разработчик — лошадь, тестировщик — телега.
НС>Давай я тебе на аналогии проиллюстрирую. НС>Вот, к примеру, надо тебе построить авто. Ты чертежи сперва нарисуешь, или начнешь на глазок железки пилить, а чертежи потом по факту нарисуешь?
Именно так, сначала рисуется диаграмма/блок схема. но это не тесты. так ведь? Это именно не формализованный концепт решения.
НС>Тесты в случае TDD это формальная спецификация, требование к тому что тебе надо реализовать. Можно, конечно, написать текст и писать по нему код с поправкой на испорченный телефон. А можно написать тест, который невозможно понять не так.
Согласен, но это громоздкое и не эффективное решение. Тесты должны рождаться когда есть что тестировать. Иначе это напоминает игры умственно отсталого ребенка: смотрите тесты не собираются, добавим заглушку, вау — тест пройден! именно такое описание TDD я встречал.
Как сказал Рич Хикки:
Вопрос: Что там случилось с каждым жучком?
Ответ: они прошли проверку типа, и они прошли все тесты.
Проведение тестов не должно побуждать кого-либо менять код без осторожности.
И представим себе, что у вас в команде выделенный тестировщик.
Что тогда с TDD?
Разработчик будет ждать от тестировщика решение?
Здравствуйте, varenikAA, Вы писали:
AA>Именно так, сначала рисуется диаграмма/блок схема. но это не тесты.
Не надо на аналогиях строить доказательства, это просто иллюстрация.
AA>Согласен, но это громоздкое и не эффективное решение.
Практика показала, что довольно эффективное. Хотя, конечно, бывает по разному.
AA> Тесты должны рождаться когда есть что тестировать.
А если в результате тестирования оказалось, что тестируемый код придется основательно переписать, иначе он не пройдет тесты? Это тоже, по твоему, эффективно?
Здравствуйте, varenikAA, Вы писали:
AA>Именно так, сначала рисуется диаграмма/блок схема. но это не тесты. так ведь? Это именно не формализованный концепт решения.
А далее нужно проверить решение практикой — те самые тесты.
Или предложишь сэкономить и запушить сразу в прод?
AA>И представим себе, что у вас в команде выделенный тестировщик. AA>Что тогда с TDD?
Остается, как есть. Тестировщик занят теми тестами, которые в тдд никогда не пишутся — сценарии, кейсы для всего приложения в целом.
То есть, имеем внятную границу. На практике разработчик залазит на территорию тестировщика, изредка, во время багфикса. И то, если репозиторий общий. Наоборот — никогда.
AA>Разработчик будет ждать от тестировщика решение?
Похоже, про роли разработчика и тестировщика ты из книжек узнал.
Например, работает ли скроллбар корректно — ответственность разработчика. А вот тестер должен убедиться, что юзер может пройти весь сценарий с ответвлениями и вариациями.
Здравствуйте, varenikAA, Вы писали:
N>>Почему этого нельзя сделать?
AA>Можно, но зачем? вы пишете тесты или программу? AA>Есть такая профессия тестировщик. Разработчик — лошадь, тестировщик — телега.
Если речь про качество, а не фичи, то все ровно наоборот — тестировщик это лошадь, а телега это разраб.
По настоящему работа программиста оценивается рабочим экземпляром.
А чтобы в коде не было багов, нужен соответствующий компилятор.
Тестировщик про которого вы пишете это вероятно проверка работы user cases
в бета-версии продукта? это не имеет отношения к TDD. Точнее любой фибек от кого бы он ни был
конечно влияет на процесс разработки. цикл разработки на мой взгляд выглядит примерно так: ( -> идея -> реализация -> проверка -> улучшение ->).
Здравствуйте, varenikAA, Вы писали:
I>>Или предложишь сэкономить и запушить сразу в прод? AA>не знаю как вы, я сначала пишу код, потом тестирую
То есть, все равно нужны тесты, в которых, по твоим словам, нету смысла
AA>По настоящему работа программиста оценивается рабочим экземпляром.
Рабочий экземпляр это только самое начало. Скажем, в норме рабочих экземпляров бывает и по десятку.
Оценивает пригодность того или иного рабочего экземпляра именно тестировщик.
AA>А чтобы в коде не было багов, нужен соответствующий компилятор.
Какой компилятор найдет алгоритмическую ошибку?
Давай на примере фильтра, годится? Ну, скажем, ты попутал some и all, findFirst и filter, и тд.
AA>Тестировщик про которого вы пишете это вероятно проверка работы user cases
Именно.
AA>в бета-версии продукта?
Разумеется. Именно тестировщик определяет степень готовности, т.е. именно он говорит, что уже альфа, бета, релиз-кандидат и тд.
AA>конечно влияет на процесс разработки. цикл разработки на мой взгляд выглядит примерно так: ( -> идея -> реализация -> проверка -> улучшение ->).
А еще оказывается, что идея не летает, и все надо начинать с начала. Цель тдд — выявить нерабочее решение как можно раньше.
Здравствуйте, varenikAA, Вы писали:
AA>Это очевидно, сначала нужен тестируемый объект.
Вообще-то исследовательские разработки ведутся как раз наоборот: сначала тесты, а потом код. Точнее, сначала описывают требования, потом под них пишут тесты, а уже потом начинают разработку.
Поясню:
1. Тебе на селфи на телефоне надо искать лица и улучшать их, чтобы девочкам нравились селфи именно с этого телефона.
2. Мы начинаем писать код? Нет, нам нет смысла его писать, потому что непонятно, с чем вообще он будет работать. Мы начинаем собирать фотки!
3. Нашли 10000 фоток. Начинаем писать код? Нет, мы наймём ребят, которые на всех фото выделят ручками лица.
4. Лица выделены. Начинаем писать код? Нет, мы наймём дизайнеров, которые в фотошопе улучшат кождое из этих фото на свой вкус.
5. Начинаем писать код? Нет, мы придумываем критерий, по которому будем считать, что лицо на фото найдено максимально верно (IoU наример) и улучшено максимально хорошо.
6. Начинаем писать код? Нет, мы разобьём выборку на 3 части: обучающую, тестовую и валидационную, выберем библиотеку для обучения нейросетей и настроим для обучения и валидации.
7. Начинаем писать код? Да, ведь у нас уже есть всё, для тестирования результата. Сочиняем архитектуру нейросети, обучаем и следим за тем, как она по подготовленным данным обучается.
8. Обучили. Пишем код для того, чтобы отправить обученную нейросеть в продакшен на телефончик.
Любая другая последовательность действий изначально обречена на провал. Надо сначала собрать данные, на которых будет работать программа. Надо описать программно сценарии работы и критерии правильности и только потом есть смысл что-то делать. По факту, при обучении тех же нейронок (а их архитектура описывается кодом на, например, Питоне) код пишется в самую последнюю очередь.
Здравствуйте, Nuzhny, Вы писали:
N>Вообще-то исследовательские разработки ведутся как раз наоборот: сначала тесты, а потом код.
Иссследовательские разработки хеллуоворлдов. Потому-что на что посерьёзней тестов не непишешься, на это уйдёт время равное времени существования вселенной. Только если на какие-то самые базовые вещи. А неумение реализовать базовый функционал без тестов-это неумение разрабатывать, aka криворукость.
Здравствуйте, smeeld, Вы писали:
S>Иссследовательские разработки хеллуоворлдов. Потому-что на что посерьёзней тестов не непишешься, на это уйдёт время равное времени существования вселенной. Только если на какие-то самые базовые вещи. А неумение реализовать базовый функционал без тестов-это неумение разрабатывать, aka криворукость.
И тут должен следовать пример, подтверждающий правоту твоих слов.
