S>Какая фантазия — реальный процесс, ты чё В мокапах, которые дают на разработку, уже показано, по какой кнопке чё происходит и всё это уже кучу раз обсуждено.

К вопросу о мире фантазий и эльфов, у которых «что в ТЗ и мокапах прописано, то и надо тестировать».

Авторы SQLite, видимо, ну очень ленивые программисты с точки зрения sambl74. Нет чтобы взять ТЗ на SQLite и написать все тесты «пользовательские юз-кейсы из мокапа» и «не писать тесты на все, потому что будет бесконечно много тестов». Но они, понимаешь ли, ленивые. Поэтому они вместо того, чтобы писать тесты, как все не ленивые люди, одной рукой генерируют тесты (TH3 генерирует 850k строк тестов), другой используют fuzzy-тестирование и в целом генерируют миллионы тестов.

При этом все равно приходят люди, пишут новые генераторы SQL-тестов и находят новые ошибки: https://www.manuelrigger.at/dbms-bugs/

Вот ведь ленивые программисты, да. Вместо того, чтобы тупо взять ТЗ и мокапы, они даже не могут написать простой тест на простое

#1 COLLATE nocase index on a WITHOUT ROWID table malfunctions

CREATE TABLE test (c1 TEXT PRIMARY KEY) WITHOUT ROWID;
CREATE INDEX index_0 ON test(c1 COLLATE NOCASE);
INSERT INTO test(c1) VALUES ('A');
INSERT INTO test(c1) VALUES ('a');
SELECT * FROM test; -- only one row is fetched

чёт не вижу тут сложного кейса. в чём тут конкретно проблема? © ленивые программисты © У нас описан сценарий, которому следует пользователь. Программа должна всегда корректно его обрабатывать. ©

Здравствуйте, Mamut, Вы писали:


AA>>обобщенные функции в CLOS наголову выше паттерн-матча, который по сути — те же if-ы.

M>обобщенные функции в CLOS являются убогим, многословным, жестко прибитым гвоздями говном по сравнению с паттерн-матчингом. Можно начать хотя бы с того, что обобщенные функции, как видно из самого названия, доступны только для объявления функций (весьма кривым способом с парой defgeneric/defmatohd, потому что иначе «самый лучший язык на земле» даже не способен понять, что происходит). Паттерн матчинг в функциональных языках доступен как для объявления функций так и внутри функций.

M>В итоге в CLOS есть defgeneric/defmethod + куча if'ов внутри. В некоторых других языках есть просто единообразный pattern matching.

Ага, только если у вас появится новый тип, то придется пройти по всей программе и добавить в каждый матчинг новый кейс,
а в случае обобщенной функции(протоколы в кложе) достаточно добавить новую реализацию для данного типа, ни строчки не меняя в месте применения.
матчинг это связывание компонентов в спагетти, которое с успехом заменяется ифчиками.

AA>Ага, только если у вас появится новый тип, то придется пройти по всей программе и добавить в каждый матчинг новый кейс,

1. Не по всей
2. Рефакторинг на то и рефакторинг

AA>а в случае обобщенной функции(протоколы в кложе) достаточно добавить новую реализацию для данного типа, ни строчки не меняя в месте применения.

Повторю опять: в лиспе есть только обобщенные и весьма ограниченные мультиметоды. Не говоря уже о дикой многословности на ровном месте. Паттерн матчинг сильно шире только мультиметодов.

AA>матчинг это связывание компонентов в спагетти, которое с успехом заменяется ифчиками.

Один и тот же человек на полном серьезе заявляет «паттерн-матчинг — по сути те же if'ы» и «матчинг это связывание компонентов в спагетти, которое с успехом заменяется ифчиками».

Ты уже определись, да. Если «паттерн-матчинг — по сути те же if'ы», то по твоей же логике if'ы точно так же «связывают компоненты в спагетти», как и pattern-matching.

Это если полностью пропустить то, что pattern-matching сильно мощнее if'ов.

Здравствуйте, Mamut, Вы писали:

AA>>Ага, только если у вас появится новый тип, то придется пройти по всей программе и добавить в каждый матчинг новый кейс,

M>1. Не по всей
M>2. Рефакторинг на то и рефакторинг

AA>>а в случае обобщенной функции(протоколы в кложе) достаточно добавить новую реализацию для данного типа, ни строчки не меняя в месте применения.

M>Повторю опять: в лиспе есть только обобщенные и весьма ограниченные мультиметоды. Не говоря уже о дикой многословности на ровном месте. Паттерн матчинг сильно шире только мультиметодов.

AA>>матчинг это связывание компонентов в спагетти, которое с успехом заменяется ифчиками.

M>Один и тот же человек на полном серьезе заявляет «паттерн-матчинг — по сути те же if'ы» и «матчинг это связывание компонентов в спагетти, которое с успехом заменяется ифчиками».

M>Ты уже определись, да. Если «паттерн-матчинг — по сути те же if'ы», то по твоей же логике if'ы точно так же «связывают компоненты в спагетти», как и pattern-matching.

M>Это если полностью пропустить то, что pattern-matching сильно мощнее if'ов.

Так я и имел ввиду, что если нужно захардкодить логику в одном месте, то матч ничем не лучше ифчиков, ну может лишь компайлер под это дело заточен.
С одной стороны хорошо, что компайлер все контролирует, с другой кодер привыкший к матчингу, работая над ифчиками может не заметить, что есть новый кейс.
Как ни крути матч или иф, все равно упираемся в опыт.

Здравствуйте, Mamut, Вы писали:

AA>>Ага, только если у вас появится новый тип, то придется пройти по всей программе и добавить в каждый матчинг новый кейс,

M>1. Не по всей
M>2. Рефакторинг на то и рефакторинг

AA>>а в случае обобщенной функции(протоколы в кложе) достаточно добавить новую реализацию для данного типа, ни строчки не меняя в месте применения.

M>Повторю опять: в лиспе есть только обобщенные и весьма ограниченные мультиметоды. Не говоря уже о дикой многословности на ровном месте. Паттерн матчинг сильно шире только мультиметодов.
в каком языке матчинг менее многословен вызова одной функции? прошу пример.

AA>в каком языке матчинг менее многословен вызова одной функции? прошу пример.

В любом, где есть паттерн матчинг. И вызовы функций — это только самая поверхность айсберга. Но посмотрим на вызовы.

Например, работа с AST (показываю только заголовки функций):

perform_analysis([], #analysis{} = A) ->

perform_analysis([Rule | Tail], Analysis0) ->

perform_analysis( #grammar{rules = Rules, initializer = Initializer}
                , Analysis) ->

perform_analysis( #rule{expression = Expression, index = Index, name = Name}
                , Analysis) ->

perform_analysis( #choice{alternatives = Alternatives, index = Index}
                , Analysis) ->

perform_analysis( #action{expression = Expression, code = Code, index = Index}
                , Analysis) ->

perform_analysis( #sequence{elements = Elements, code = Code, index = Index}
                , Analysis) ->

... и еще десяток

В Лиспе/Кложуре надо сначала указать тип параметра/параметров, а потом максимум, что с ними можно сделать — это лукапы по :keys

При этом если надо обработать какой-нибудь corner-case, любой вариант добавляется одной левой. Типа

perform_analysis( #choice{alternatives = [], index = 3}
                , Analysis) -> ... обработали этот крайний случай
perform_analysis( #choice{alternatives = [[]|[#expression{}]], code = []}
                , Analysis) ->  ... обработали этот крайний случай
...

Простые случаи вообще выродятся в Лиспе неизвестно во что:

quote_for_regexp_class(<<$\\>>) -> <<$\\, $\\>>; % backslash
quote_for_regexp_class(<<$/>>) -> <<$\\, $\\, $/>>; % closing slash
quote_for_regexp_class(<<$]>>) -> <<$\\, $\\, $]>>; % closing bracket
quote_for_regexp_class(<<$^>>) -> <<$\\, $\\, $^>>; % caret
quote_for_regexp_class(<<$->>) -> <<$\\, $\\, $->>; % dash

Вернее, в Лиспе тут как раз будет какой-нибудь cond с кучей условий.

Здравствуйте, Mamut, Вы писали:

M>4. Почему ты уверен, что спецификация описывает поведение пользователя, как человека. Например, в видео, которе ты, видать, никогда и не посмотришь, никакого пользователя не было. Была система под нагрузкой, которая раз в один-два месяца падала с невнятной ошибкой.

Посмотрел, чё уж. В итоге же невнятная ошибка воспроизводилась простым тест-кейсом. Ну и одновременная конкурентная работа с одним файлом конечно источник проблем.

M>>>А, месье из мира эльфов и фей.

S>>Да, из мира где выпускается MVP и потом по результатам тестирования и фидбеку от пользователей допиливается функционал приложения, которое всегда стабильно работает на заданном наборе сценариев.

M>Прекрасноэ, конечно.

M>Сначала «программисты ленивые, что не пишут тесты на все кейсы», потом «а что сложного в кейсе», потом «не, ну мы нифига не пишем все тесты, мы пишем что смошгли, а потом ждем баг репортов от тестеров и пользователей».

Да, у нас так

M>>>Ты это говоришь и описываешь какие-то идеальные тесты и кейсы, которые все зарание продумали, тзательно записали в спецификации, а потом каждый из них написан и протестирован программистом.

S>>Да, так и работаем. Ощути тленность своего бытия

M>Вы не рабоатете так. Вы работаете реально по принципу «написали те тесты, что смогли придумать, ждем отзыва от тестеров и реальных пользователей. получили отзыв о баге, починили баг, написали тест». Ну то есть ровно так, как работают все.

Ну тебе конечно виднее.

M>«Мокапы, кнопки». Видео посмотри один раз уже, да.

Да посмотрел уже, не вижу проблемы. Была непонятная ситуация, написали тест кейс, который воспроизводит эту ситуацию на раз, починили. Норм же.

S>Посмотрел, чё уж. В итоге же невнятная ошибка воспроизводилась простым тест-кейсом.

Ты даже не понял, как эту ошибку нашли

S>Ну и одновременная конкурентная работа с одним файлом конечно источник проблем.

Именно. И, видимо, согласно тебе, «непонятно, что там сложного», да? А люди, которые не написали этот тест кейс — «ленивые чо». Так?


M>>Сначала «программисты ленивые, что не пишут тесты на все кейсы», потом «а что сложного в кейсе», потом «не, ну мы нифига не пишем все тесты, мы пишем что смошгли, а потом ждем баг репортов от тестеров и пользователей».

S>Да, у нас так

Это у всех так. Только почему-то именно вы отличные молодцы, а остальные — ленивые чо. Хотя вы точно так же не покрываете тестами все тест-кейсы.

M>>Вы не рабоатете так. Вы работаете реально по принципу «написали те тесты, что смогли придумать, ждем отзыва от тестеров и реальных пользователей. получили отзыв о баге, починили баг, написали тест». Ну то есть ровно так, как работают все.

S>Ну тебе конечно виднее.

Ты это пишешь прямым текстом.

M>>«Мокапы, кнопки». Видео посмотри один раз уже, да.

S>Да посмотрел уже, не вижу проблемы. Была непонятная ситуация, написали тест кейс, который воспроизводит эту ситуацию на раз, починили. Норм же.

Не «написали тест кейс, который воспроизводит ситуацию», а:

— кейс происходил в системе, работающей под нагрузкой, раз в один-два месяца
— причины ошибки были неизвестны
— воспроизвести ошибку на тестовых машинах не получалось в течение полугода
— пришлось генерировать кучу вариантов работы с системой, чтобы найти ту последовательность действий, которая приводит к ошибкам
— хорошо, QuickCheck (использовання для генерации тестов библиотека) умеет «схлопывать» сгенерированные тесты, и находить более-менее минимальный набор действий для воспроизведения ошибки
— в итоге только после генерации тестов и схлопывания их был найден минимальный набор действий для тест-кейса

sambl74: не, ну чо там такого. простой тест кейс, написали этот тест кйс, починили, че там такого. Ленивые программисты, нет чтобы по ТЗ написать тест-кейсы.

Здравствуйте, Mamut, Вы писали:

S>>Посмотрел, чё уж. В итоге же невнятная ошибка воспроизводилась простым тест-кейсом.

M>Ты даже не понял, как эту ошибку нашли

Чё бомбит то тебя так?