Здравствуйте, Codealot, Вы писали:
I>>Например, результат "подписка отменена", может просто выглядеть как правильный, а на самом деле подписка чудом воскрешается спустя какое то время.
C>Предлагаю гнать взашей "программистов", у которых происходят такие чудеса.
Что бы это сделать, надо сначала заподозрить существование такой проблемы, потом придумать и отладить тест, который укажет на ответсвенное лицо. Пока проблема не выявлена, тем "программистам" и предъявить нечего.
Ну как, накидаешь тестик, который обнаружит воскрешение подписки за один...два...десять прогонов?
Здравствуйте, Codealot, Вы писали:
S>>2) Какова сложность модели которую он описывает?
C>Ну, панель управления — та, которая новая — это сотня чекбоксов максимум.
Сотня чекбоксов это числа: от 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 до 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111.
Времени жизни Вселенной хватит для тестирования всех комбинаций, как думаете?
Здравствуйте, Ikemefula, Вы писали:
S>>С чем не согласен: а как же, например, знаменитое 0xcdcdcdcd, которое так нам помогало все эти годы? Не говоря про null reference / out of range exceptions и тому подобное. Всё это — автоматизированный поиск неизвестных проблем и очень эффективный. Я не могу сосчитать, сколько багов одному только мне удалось так выловить.
I>Автоматизированый, но это не тесты.
Не хочу буквоедствовать, но вы первый написали обобщёно (про тесты — ни слова):
I>Автоматизировать можно только поиск известных проблем.
Вот и я обобщил то и другое как... назовём это «средства автоматизации поиска проблем». Для меня ассерты, шахматка и т.п. это зародыши юнит-тестов. Не знаю, понятно ли написал — ну, они работают на низовом уровне. Когда мы пытаемся подняться выше (в направлении сценариев), где-то на этом пути и появляются юнит-тесты.
S>>Ещё есть статические кодоанализаторы. Лично я их считаю полной фигнёй на основании своего личного опыта.
I>Да почему же фигня? Статическая типизация автоматически страхует тебя от целого класса проблем. В данном случае роль статического кодоанализатора выполняет сам компилятор. Разумеется, это все не бесплатно — код нужно писать так, что бы всегда полагаться на систему типов. И в этом случае компилятор сработает максимально надёжно, у человека ничего подобного не выйдет.
А я и про компилятор скажу то же самое. Вернее, уже сказал. Тут рядом пробегала тема про low-code/no-code, там с подачи Sinclair'а обсуждалась цена конвееризации, которую привносит компилятор. А за что она уплачивается? Ладно, если за скорость и отказ от интерпретации. Но вот в случае TypeScript я вообще не вижу, за что. Всё, что он отлавливает, настолько тривиально, что мне с успехом его заменяет лог с exception'ами при первом же запуске. Вот ну ни одной ошибки в прод не попало, ни разика. Другие попадали, некоторые типы ошибок — чаще, чем хотелось бы, но компилятор бы их не словил. Отсюда и отношение такое.
Ну, это, видимо, у кого какой опыт. Я не виноват, что блюющий радугой единорог лично мне пользы ни разу не принёс. Я, наоборот, оговорился: есть в нашей индустрии титаны, которые его хвалят.
Я могу только что сказать. Вот недавно была статься на Хабре очередная, от авторов единорога. Они рекомендовали использовать оформление, чтобы не допускать ошибок сравнения полей. Оформление!!! Я для таких целей использую макросы. Может, в этом дело? Поэтому мне кодоанализаторы не приносят пользы, хе-хе?
I>А вот те анализаторы, что работают уже поверх такого кода, большей частью мало чего добавляют. Здесь такая вещь, что индустрия постоянно пополняется контингентом без хорошего образования, и чем дальше, чем больше доля такого контингента. Как правило, у таких навыки кодинга достаточно низкие. И вот тогда эти анализаторы находят тучи всякой мелочевки.
S>>С чем снова не согласен, но теперь уже с другой стороны: а вот не на каждый сюрприз, найденный «ручниками», в принципе можно создать автотест, который приносил бы пользу. Однажды я работал над HTML-игрушкой.
I>Вот это достаточно сложная область для тестирования, тк в игрушке количество всех путей обычно превышает даже самые дикие ожидания. я тут пилю игрушку для собственного развлечения, но вот тестировать я уже вспотел. И основная проблема именно со сценариями. Типа "через N часов полетов выясняем, что в самом начале нужно было выполнить ниоткуда не очевидное условие".
Да это неважно, что она игрушка. Это просто окошко с натянутым фоном + кастомные контролы. Самый обычный гуйский гуй.
>> Но вот тебе задачка на порядок проще: покрой известный тебе баг тестами. Покажи удаль. Закончилось всё тем, что он стал педалить импорт paths из Фотошопа (необходимость прописывать paths в Фотошопе легла на плечи художника). Збс! Раньше было два набора данных, из рассинхрона которых могли возникнуть баги — теперь их стало три. I>Это ж классика Тестируй или нет, а рассинхрон всё равно возьмёт своё. Это не решается тестами.
Забыл написать. Позже товарищ увлёкся нейронными сетями. Хорошо, что позже — чувствую, был бы цирк ещё тот, с автонахождением «правильных» координат.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Ikemefula, Вы писали:
I>>Ты снова решил "поиграть в доказательства" но почемуто пропускаешь половину моего утверждения мимо ушей.
НС>Что я пропускаю?
Разумеется. Очевидно, что мою фразу ты интерпретируешь не так, как интерпретирую её я. Вот и всё.
> Каким волшебным образом неизвестные проблемы, выявляемые сценарными тестами, становятся известными?
Если ты написал сценарий, то это и значит, что ты описал проблему. Конкретные баги конечно же неизвестны при этом, до тех пор, пока тест не упадет.
I>>Теперь вернемся к твоему утверждению: "Тесты на известные сценарии отлавливают любые проблемы, не только известные"
НС>Любые в данном случае означает "любого вида".
Не знаю, что за классификацю ты подразумеваешь под словом "вид". Виды багов как Гейзенбаг, воспроизводится у юзера, но не воспроизводится ни у девелоперов, ни у тестеров.
Пишешь в "вот последовательность, не работает", и в ответ "а у нас есть точно такой тест и с ним все в порядке"
> Ты же пытаешься подменить слово "любые" на слово "все".
В том то и дело, что тебе самому надо было убрать слово "любые" и заменить его на "все, удовлетворяющие конкретным условиям теста".
Тогда сразу понятно, что есть и ограничение — конкретные условия теста.
То есть, как ни крути, снова не любые.
НС>>>Тем не менее твое заявление неверно. I>>А аргумент то какой?
НС>Факт. Сценарные тесты способны отлавливать неизвестные проблемы
И снова неадекватно смелое обобщение Сценарии способны отлавливать часть неизвестных багов. Вот так будет правильно. Слово "часть" выбрасывать нельзя, хотя менеджеры очень любят это дело. Ты случаем не менеджер какой? А то вечно такие детали упускаешь.
Здравствуйте, Shtole, Вы писали:
S>Не хочу буквоедствовать, но вы первый написали обобщёно (про тесты — ни слова):
I>>Автоматизировать можно только поиск известных проблем.
S>Вот и я обобщил то и другое как... назовём это «средства автоматизации поиска проблем». Для меня ассерты, шахматка и т.п. это зародыши юнит-тестов. Не знаю, понятно ли написал — ну, они работают на низовом уровне. Когда мы пытаемся подняться выше (в направлении сценариев), где-то на этом пути и появляются юнит-тесты.
Принципиальное отличие ассертов от тестов в том, что ассерты непрерывны, а тесты — дискретны.
В силу этого ловят разные классы багов.
Скажем, "assert результат удовлетворет свойству" работает всегда, т.е. непрерывен. А вот написать юнит-тест, которые покроет всё множество входов-выходов мягко говоря невозможно.
S>А я и про компилятор скажу то же самое. Вернее, уже сказал. Тут рядом пробегала тема про low-code/no-code, там с подачи Sinclair'а обсуждалась цена конвееризации, которую привносит компилятор. А за что она уплачивается? Ладно, если за скорость и отказ от интерпретации. Но вот в случае TypeScript я вообще не вижу, за что. Всё, что он отлавливает, настолько тривиально
Статическая типизация это не чудо, а инструмент проектирования. Работает при следующих условиях
1. правильный конфиг, через код ревью
2. правильный код, с указанием типов
3. код ревью, что бы не было приведения к any, unknown и тд
4. честный компилятор
S>Ну, это, видимо, у кого какой опыт. Я не виноват, что блюющий радугой единорог лично мне пользы ни разу не принёс. Я, наоборот, оговорился: есть в нашей индустрии титаны, которые его хвалят.
Просто так тайпскрипт не даёт бенефита. Это ты должен писать такой код, ошибки в котором будут находиться компилятором.
То есть, если ты хочешь, то к твоим услугам компилятор. Не хочешь — тогда он тебе вовсе не нужен.
Что бы был бенефит, тебе надо правильно описывать типы, тогда компилятор сделает проверку, вывод и тд.
Фактически, статическая типизация устраняет целый класс проблем вида "передали не то и не туда", которые вообще говоря слишком многочисленны в большой кодовой базе.
Штука в том, что юнит-тесты и типы не заменяют друг друга, а дополняют, классы проблем у каждого метода разные.
Типы не ловят поведенческие ошибки, а юнит-тесты могут спокойно проглатывать или игнорировать ошибки типов.
I>>Это ж классика Тестируй или нет, а рассинхрон всё равно возьмёт своё. Это не решается тестами.
S>Забыл написать. Позже товарищ увлёкся нейронными сетями. Хорошо, что позже — чувствую, был бы цирк ещё тот, с автонахождением «правильных» координат.
Да, похоже, что "правильные координаты" это вечная проблема.
Здравствуйте, Ikemefula, Вы писали:
I>>>Ты снова решил "поиграть в доказательства" но почемуто пропускаешь половину моего утверждения мимо ушей. НС>>Что я пропускаю? I>Разумеется.
Это был вопрос.
I> Очевидно, что мою фразу ты интерпретируешь не так, как интерпретирую её я. Вот и всё.
Фраза твоя вполне однозначна, как не интерпретируй.
>> Каким волшебным образом неизвестные проблемы, выявляемые сценарными тестами, становятся известными? I>Если ты написал сценарий, то это и значит, что ты описал проблему.
Нет. Это значит что я описал сценарий. Описание проблемы это негативный тест. Описание сценария — позитивный.
НС>>Любые в данном случае означает "любого вида". I>Не знаю, что за классификацю ты подразумеваешь под словом "вид".
В контексте разговора вид означает, что отлавливаются и известные и неизвестные.
>> ?Ты же пытаешься подменить слово "любые" на слово "все". I>В том то и дело, что тебе самому надо было убрать слово "любые" и заменить его на "все, удовлетворяющие конкретным условиям теста".
Чтобы тебе было проще не признавать, что ты написал ерунду? Нет уж.
I>То есть, как ни крути, снова не любые.
Ага, очередная борьба с чучелком, кто бы сомневался.
НС>>Факт. Сценарные тесты способны отлавливать неизвестные проблемы I>И снова неадекватно смелое обобщение
Это не обобщение, это наблюдаемый факт.
I>Сценарии способны отлавливать часть неизвестных багов.
ЧТД.
I> Вот так будет правильно. Слово "часть" выбрасывать нельзя,
Можно. А вот в твоем исходном заявлении это слово следовало бы добавить, иначе оно просто ложное.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>> Очевидно, что мою фразу ты интерпретируешь не так, как интерпретирую её я. Вот и всё. НС>Фраза твоя вполне однозначна, как не интерпретируй.
Выглядит так, будто ты лучше знаешь, что же я имел ввиду. Телепатия? Похоже, ты и мысли не допускаешь, что у собеседника в голове может быть чтото другое.
>>> Каким волшебным образом неизвестные проблемы, выявляемые сценарными тестами, становятся известными? I>>Если ты написал сценарий, то это и значит, что ты описал проблему. НС>Нет. Это значит что я описал сценарий. Описание проблемы это негативный тест. Описание сценария — позитивный.
Это значит, что мы с тобой по разному используем слово "проблема". В моем понимании баг и проблема это разные вещи, не эквивалентные.
I>>Не знаю, что за классификацю ты подразумеваешь под словом "вид". НС>В контексте разговора вид означает, что отлавливаются и известные и неизвестные.
Точнее, отлавливается часть известных, и часть неизвестных. Именно что часть, а не "любой", "все", "какие то".
То есть, любой тест всё равно остаётся точечной проверкой, сколько бы известных или неизвестных он ни отлавливал.
I>>В том то и дело, что тебе самому надо было убрать слово "любые" и заменить его на "все, удовлетворяющие конкретным условиям теста". НС>Чтобы тебе было проще не признавать, что ты написал ерунду? Нет уж.
... I>>То есть, как ни крути, снова не любые. НС>Ага, очередная борьба с чучелком, кто бы сомневался.
Вот-вот. Снова тебе надо найти крайнего, как будто это я тебя заставил попутать "любой", "все", "часть" и "целое"
В который раз спрашиваю — с какой целью ты начинаешь со мной переписываться, если по твоему я использую тебя как чучелко?
НС>>>Факт. Сценарные тесты способны отлавливать неизвестные проблемы I>>И снова неадекватно смелое обобщение
I>>Сценарии способны отлавливать часть неизвестных багов. НС>
ЧТД.
То есть, если переформулировать используя конкретный термин, все становится в порядке. С этим ты согласен?
Штука в том, что сценарии и тесты вообще отлавливают не только баги. И тесты вообще отлавливают не только баги. Например, красный тест может означать, что никакого бага нет, а просто тест запустили не в том окружении. А может быть сам сценарий больше невалидный. А может быть есть ошибка в самом тесте. А может быть есть ошибка в другом тесте, просто возникла зависимость между тестами.
I>> Вот так будет правильно. Слово "часть" выбрасывать нельзя, НС>Можно.
Без этого слова смысл другой, т.е. остаётся неопределенность "не то все, не то любые, не то какие то конкретные".
Пример — "люди смертны" и "часть людей смертны".
Идея ясна?
Здравствуйте, Ikemefula, Вы писали:
S>>Ну, это, видимо, у кого какой опыт. Я не виноват, что блюющий радугой единорог лично мне пользы ни разу не принёс. Я, наоборот, оговорился: есть в нашей индустрии титаны, которые его хвалят.
I>Фактически, статическая типизация устраняет целый класс проблем вида "передали не то и не туда", которые вообще говоря слишком многочисленны в большой кодовой базе.
Я, представьте себе, слышал вещь или две о статической типизации. Речь тут идёт о личных впечатлениях от реальной пользы на практике. Очень продолжительной практике, если что.
Здравствуйте, Ikemefula, Вы писали:
C>>Сраный гуй это "огромная и сложная кодовая база"? I>UI всегда было крайне сложно тестировать в силу обилия последовательностей.
Здравствуйте, Ikemefula, Вы писали:
I>Что бы это сделать, надо сначала заподозрить существование такой проблемы, потом придумать и отладить тест, который укажет на ответсвенное лицо.
Достаточно, чтобы этот баг зарепортили или обнаружили тестеры, а потом сесть и почитать код.
Здравствуйте, Ikemefula, Вы писали:
I>Раскрой глаза — в винде чуть ли не на каждом скрине ты видишь десятки и даже сотни больших и мелких фич, которые в целом работают хорошо и стабильно. Каким чудом это достигается?
Методами "тысячи макак за клавиатурами" и "пользователи вместо тестеров", а также кодом, многие части которого не меняли уже десятки лет.
Здравствуйте, Shtole, Вы писали:
S>Знал я одного такого, всё ходил: «Да я!», «Да мы!», «Формошлёпство!», «Макаки джаваскриптовые!». (Типус этот писал кое-какие алгоритмы на плюсах и по этой причине почему-то считал себя высшей формой органической материи). Ему поверили, дали полностью свёрстанный макет, где все расстояния были прописаны в пикселях, а тайминги в миллисекундах, и ссылку на CEF3 — просто возьми да имплементируй. Сделаешь? Чувак ответил утвердительно: это ж сраный гуй! Для приплюснутого алгоритмиста — раз плюнуть! Ну вот, через неделю приходит он с вопросом: «А как в вашем макакачьем джаваскрипте сделать ::Sleep()?». Ему ответили, шерсть на носу, но немного не то, что он хотел услышать, шерсть на носу. Так вот, больше не ходит и сраным гуём не обзывается.
Я писал и гуи в том числе. И куда более сложные по функционалу, чем эта сраная панель управления.
Здравствуйте, Codealot, Вы писали:
S>>Ога, всего лишь сотня... C>А сколько ты назовешь?
А при чем здесь я? Я мало знаю софта, разве что для видео и аудио монтажа + всяческие кады, где бы было
под 100 чекбоксов (и это только чекбоксы). Соотв. надо учитывать из возможное взаимодействие (как бы 100!),
что лишний раз говорит о сложности модели, которое это ui описывает. Где-то просто не доглядели, бывает.
Понятно, что речь идет о настройках изолированных компонент, т.е. речи о 100! нету, но все же эту кусок
крайне большого и сложного кода, откуда то что-то убрали, забыли убрать в др. месте. Или абстракции кривые,
раз надо крутить в нескольких местах. Ну бывает, поправят.
S>>Ну как бэ да, настройки ОС же, точнее всяческих подмодулей. И как это все вместе взаимодействует тот еще S>>вопрос. C>Как работают другие подсистемы — это уже совсем отдельный вопрос.
Да нет, это все тот же вопрос. Речь идет об ui для настройки этих подсистем.
Здравствуйте, Ikemefula, Вы писали:
I>Просто так тайпскрипт не даёт бенефита. Это ты должен писать такой код, ошибки в котором будут находиться компилятором.
И это работает с обеих сторон. В том смысле, что язык и компилятор должны быть достаточно выразительны.
Ну, вот из примеров, которые мы сегодня разбирали со студентами: есть у нас некотрое арифметическое выражение, представленое в виде AST.
Язык выражений — примитивный: целые константы, переменные, сложение/умножение/вычитание/деление.
В C# мы бы, наверное, имели некоторый абстрактрый тип Expr и шесть его потомков.
Теперь, собственно задача: сделать преобразование произвольного выражения в рациональное.
Рациональное выражение — это когда во всём дереве операция деления ровно одна, и она — в корне. Ниже по дереву никаких делений нет.
Реализация — примитивна. Можно навелосипедить на визиторах, можно — на паттерн матчинге (если язык позволяет).
C# паттерн матчинг позволяет, так что вроде всё хорошо.
Вопрос: а как проверить корректность?
TDD-подход: закодить функцию bool isRational(Expr e), закодить несколько тест кейзов с разными выражениями, делая Assert.True(isRational(makeRational(e)));
Defensive programming подход: добавить в хвост makeRational() стейтмент Debug.Assert(isRational(result)),
FP-подход: напилить алгебраический тип Polynome, определённый как PolyAdd, PolyMul, PolySub, Const, Var. В отличие от Expression, PolyDiv в нём не участвует.
PolyDiv и прочие PolyXXX — аналоги обычных Div/Add/Mul/Sub, только у них аргументами не Expr, а Poly.
После этого определяем тип функции makeRational как Expr->PolyDiv и наслаждаемся проверками компилятора: он проследит и за полнотой покрытия, и за корректностью.
Без алгебраических типов всё это описать будет труднее, и не будет гарантий полноты покрытия.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Codealot, Вы писали:
BFE>>Времени жизни Вселенной хватит для тестирования всех комбинаций, как думаете? C>Если делать всё исключительно тупостью и грубой силой — то да, не хватит.
Вооот! А если делать по умному, то можно ошибиться в хитросплетениях рассуждений, когда зависимость одного чекбокса от другого должна отсутствовать, а по факту она есть и это ошибка, которая должна быть выявлена тестом. Давайте, предложите решение для задачи: есть два чекбокса, они определяют функциональность, которая не зависит одна от другой. Например, первый чекбокс определяет, что по дабл клику на вертикальной линии дерева кликнутая ветка должна схлопываться, второй определяет, нужно ли использовать 3D стиль. Предложите способ без перебора, который позволяет выявить, что функционирование одного режима никак не влияет на функционирование другого.
Здравствуйте, Codealot, Вы писали:
I>>Что бы это сделать, надо сначала заподозрить существование такой проблемы, потом придумать и отладить тест, который укажет на ответсвенное лицо.
C>Достаточно, чтобы этот баг зарепортили или обнаружили тестеры, а потом сесть и почитать код.
Здравствуйте, Shtole, Вы писали:
S>Я, представьте себе, слышал вещь или две о статической типизации. Речь тут идёт о личных впечатлениях от реальной пользы на практике. Очень продолжительной практике, если что.
У меня практики >20 лет, писал сначала на ассемблере, потом на си++, на питоне, C# и это не считая всяких мелких экспериментов. Последние лет 9 на тайпскрипте и джаваскрипте.
Вернее, уже сказал. Тут рядом пробегала тема про low-code/no-code, там с подачи Sinclair'а обсуждалась цена конвееризации, которую привносит компилятор. А за что она уплачивается? Ладно, если за скорость и отказ от интерпретации. Но вот в случае TypeScript я вообще не вижу, за что. Всё, что он отлавливает, настолько тривиально, что мне с успехом его заменяет лог с exception'ами при первом же запуске. Вот ну ни одной ошибки в прод не попало, ни разика. Другие попадали, некоторые типы ошибок — чаще, чем хотелось бы, но компилятор бы их не словил. Отсюда и отношение такое.
Тестируй или нет, а рассинхрон всё равно возьмёт своё. Это не решается тестами. 
но почемуто пропускаешь половину моего утверждения мимо ушей. 
Сценарии способны отлавливать часть неизвестных багов. Вот так будет правильно. Слово "часть" выбрасывать нельзя, хотя менеджеры очень любят это дело. Ты случаем не менеджер какой? А то вечно такие детали упускаешь.
