В каком смысле он «поверхностный»? Сравнил эту статью, и ту, на которую дали ссылку выше, и увидел тот же самый объём фактически той же самой информации. В вашем случае есть ещё вступление про ваш продукт.
> Типа ИКС = рандом от 1 до 20, а ИГРЕК д.б. ИКС * 2.
тоже не очень люблю. Потому что для получения эталонного значения нам нужно будет повторить тестируемый алгоритм (или его часть) в тесте, что как-то не очень красиво :-)
> Если у нас всё ок с кодом, то результаты и не будут меняться — рандом у нас или «константа».
В ситуации, о которой идёт речь в посте — будут. В качестве эталонных значений были взяты статистические, а в качестве исходных данных — рандом. Потому, волей случая, тест может падать. Потому этот рандом оставлять нельзя.
Тесты должны быть консистентными, потому их запускают в управляемом (или вообще изолированном) окружении.
Результаты тестов не должны изменяться от запуска к запуску.
> Но опять же, конечно, не как основной метод.
Даже как неосновной. Для первоначальной ручной проверки — да. Для последующего автоматического запуска — нет. Научились применять покерные правила к картам — составляйте фикстуры, убирайте рандом.
> Да даже с другой стороны — а реальные юзеры это не рандом вообще? Это тот ещё случайный случай.
Я не совсем понимаю при чём тут это вообще. Я комментировал тестирование, а не эксплуатацию. После того как код отлажен, он должен одинаково предсказуемо работать в тестовом окружении (на основе фикстур) и и продакшне («рандомные» действия пользователей).
100% покрытие никто не может обеспечить, потому покрывают только то, что вам важно :-)
Так или иначе — тесты достовернее комментариев и процесса, в который с обеих стороны вовлечены люди: один пишет комментарии, другой их читает и помнит все зависимости своего кода.
«номерация у нас трехзначная, поэтому LENGTH( `src` ) >3, отсекаем исходящие вызовы»
Это рабочий скрипт, который работает для вашей конфигурации. Соглашусь, что тривиальный запрос + тривиальный код вокруг него — не такая и проблема, чтобы искать и подпиливать его под себя, вместо того, чтобы написать на коленке за 15 минут.
Я же подчеркнул «с точки зрения используемой памяти». Я веду дискуссию исключительно в этом направлении, и это подчеркнул в каждом из моих комментариев.
Потому я и отвечал на комментарий «Но ведь ключ в хеше всё-равно останется)», намекая, что с точки зрения используемой (под хранение данных свойства или «обычной переменной») памяти присваивание null и использование delete равнозначны.
ps: а, понял, комментарий, на который я отвечал, вообще никак не связан с памятью уже, а просто о «порядке»
В каком смысле он «поверхностный»? Сравнил эту статью, и ту, на которую дали ссылку выше, и увидел тот же самый объём фактически той же самой информации. В вашем случае есть ещё вступление про ваш продукт.
Что я упускаю?
Хотя лично я и вещи вроде:
> Типа ИКС = рандом от 1 до 20, а ИГРЕК д.б. ИКС * 2.
тоже не очень люблю. Потому что для получения эталонного значения нам нужно будет повторить тестируемый алгоритм (или его часть) в тесте, что как-то не очень красиво :-)
В ситуации, о которой идёт речь в посте — будут. В качестве эталонных значений были взяты статистические, а в качестве исходных данных — рандом. Потому, волей случая, тест может падать. Потому этот рандом оставлять нельзя.
Результаты тестов не должны изменяться от запуска к запуску.
> Но опять же, конечно, не как основной метод.
Даже как неосновной. Для первоначальной ручной проверки — да. Для последующего автоматического запуска — нет. Научились применять покерные правила к картам — составляйте фикстуры, убирайте рандом.
> Да даже с другой стороны — а реальные юзеры это не рандом вообще? Это тот ещё случайный случай.
Я не совсем понимаю при чём тут это вообще. Я комментировал тестирование, а не эксплуатацию. После того как код отлажен, он должен одинаково предсказуемо работать в тестовом окружении (на основе фикстур) и и продакшне («рандомные» действия пользователей).
Определять правила соответствия карт комбинации нужно на заданных данных (фикстурах), а не на основе генератора псевдослучайных чисел.
Так или иначе — тесты достовернее комментариев и процесса, в который с обеих стороны вовлечены люди: один пишет комментарии, другой их читает и помнит все зависимости своего кода.
Это рабочий скрипт, который работает для вашей конфигурации. Соглашусь, что тривиальный запрос + тривиальный код вокруг него — не такая и проблема, чтобы искать и подпиливать его под себя, вместо того, чтобы написать на коленке за 15 минут.
Я же подчеркнул «с точки зрения используемой памяти». Я веду дискуссию исключительно в этом направлении, и это подчеркнул в каждом из моих комментариев.
Потому я и отвечал на комментарий «Но ведь ключ в хеше всё-равно останется)», намекая, что с точки зрения используемой (под хранение данных свойства или «обычной переменной») памяти присваивание null и использование delete равнозначны.
ps: а, понял, комментарий, на который я отвечал, вообще никак не связан с памятью уже, а просто о «порядке»
www2.host они ещё ни разу не запрашивали — следовательно он будет запрошен с вашего ДНСа (и только после этого заботливо закеширован), разве не так?