В идеале так и должно быть — изменения в одном модуле не должны сказываться на функциональности другого.
На практике, конечно, такое не всегда возможно, но зависимости модулей можно учитывать.
Например, изменения в компонентах, связанных с правами доступа (самое «ядерное» ядро) должны быть протестированы все модули, которые от него зависят — то есть практически вся система.
А если вся команда «пилила» лишь функционал интернет магазина, то нет смысла (да и времени) тестировать модуль «Обратная связь».
А вообще, в основной чеклист может быть занесено по одному — два не сложных теста каждого модуля, чтобы тестировщик хотя бы зашел в них и проверил живые ли они.
>… времени на их развитие уделяют меньше, что очень печально
Очень печально что далеко не все тестировщики уделяют время на собственное развитие.
Чтобы быть хорошим тестировщиком (ИМХО), надо иметь особый склад ума и характера и любить свою работу, постоянно изучая специалзированную литературу самостоятельно.
Из своих знакомых я знаю только одного человека, которому действительно нравится тестирование и который посещает кучу конференций и растет профессионально. А так же знаю пару человек, кто в прямую говорят что занимается этим временно, и на самом деле это не особо интересно.
А чек-листы лучше составлять по каждому модулю, если система модульная. Это удобно. Можно прямо по репозиторию смотреть, изменили ли разработчики код модуля к текущему релизу. Если да, то, очевидно, нужно прогнать тесты этого чек-листа.
Ну и должен быть глобальный чек-лист, который проверяется для КАЖДОГО релиза. Там должен быть самый главный и важный функционал, который ни в коем случае не должен сломаться.
Ну, на мой взгляд, все-таки увеличение производительности есть, просто оно не значительное и не там, где бы вам хотелось. Вы рассматриваете подготовленные запросы практически как хранимые процедуры.
Если рассматривать что все-таки в рамках одного скрипта возможны одинаковые запросы. Например, если мы обновляем что-то на сайте и запускаем типовые INSERT/UPDATE.
Если каждый человек будет заказывать платную детализацию по счету каждый месяц, может Билайн обогатиться и перестанет всякими ухищрениями красть списывать деньги абонентов?
Ну значит надо по любому зарефакторить такой публичный метод, он слишком много на себя берет. ну, например, применить к нему выделение стратегии и тестировать каждую стратегию изолированно и не зависимо от класса. Пусть одна зависит от синуса, другая от косинуса, третья от звезд на небе, на каждую будет нормальный тест.
На практике еще никогда не возникало желания и необходимости тестировать приватные методы. На мой взгляд, в этом случае явный признак — проблема в архитектуре.
> А протектед-методы надо тестировать?
Надо, через тесты на публичные методы конкретных реализаций класса
>Абсолютно всё то же самое актуально и для публичных методов и даже для целых классов.
Опубликованные методы и классы не так просто выпилить, особенно если ты не владеешь всем кодом проекта и публикуешь API. Тут поможет только deprecated и делегирование
>С точки зрения моего класса, все его приватные методы являются открытыми для класса-обладателя.
Конечно, ибо эти методы относятся только к нему и актуальны только для него. У наследника доступа нет, но есть своя реализация и приватные методы, ему нет дела до приватных методов своего родителя, потому что они его не касаются.
>А если я напишу приватную функцию вычисления синуса?
Раз она приватная, значит она нужна (касается) только для этого класса и он ее использует для своей реализации. Лучше протестировать то, для чего она используется. Завтра синус менеджеры заменят на косинус и в чем смысл теста?)
При рефакторинге кода, написанные тесты на приватные методы составят незабываемое «удовольствие». Простейшее перемещение или изменение сигнатуры приватного метода доставит еще и кучу проблем с его тестами. В итоге, они просто будут скорее всего удалены, либо рефакторинг отложен со словами «ну вот, покрыл тестами, работает, да ну и фиг с ним, с дублированием кода».
Приватные методы они на то и приватные, что в любой момент могут быть удалены, переписаны, дополнены, перемещены, раздроблены на более мелкие части. Если проект развивается здоровым путем, то это для него нормальная практика.
ну и почему отличная команда не может получиться из фрилансеров?
Человеку, который собрал отличную команду из фриласеров — двойное уважение на мой взгляд.
Посмешило многое на сайте горе-цмс, а особенно вот это:
«Памятка системному администратору по вопросам профилактики от вирусов и паразитического софта:
— Обязательное отключение поддержки PHP на Ваших серверах и зонах хост-провайдеров.
Помните, что только при поддержке PHP можно извне завести Вам зловредный код без Вашей воли при неизвестных злоумышленику параметрах доступа по FTP»
Самый смешной был случай, когда я понял что это утопия, это когда кто-то выложил разэнкоженный файл проверки лицензии продукта, который старательно энкодился зенд-гардом платным.
Так в этом файле даже переносы строк были аккуратнее расставлены, чем в оригинальном ))))
Это еще раз доказывает, что смысла в такой навороченной обфускации нет.
Если кому-то понадобится очень, все равно напишет деобфускатор. А какой ущерб производительности от такой обфускации — вообще жесть, одни евалы чего стоят.
У меня была задача сделать код проекта не читаемым. Долго искал обфускаторы php-кода, все слишком навороченные и многие просто не работают в режиме, когда есть часть кода обфусциорваная, а часть нет. В итоге, написал сам из 100 строчек, используя php-токинайзер и md5.
Прекрасно вас понимаю, сам жду важных багфиксов.
Всем хочется, чтобы важные именно для него баги были поправлены в кратчайшие сроки, но вы же, как разработчик системы должны прекрасно понимать, что приоритеты такие приоритеты…
Можно же запустить инсталлятор из консоли (CLI-режим), положив предварительно конфиг с параметрами установки и запускать это все одно командой. Да, придется подождать, пока все развернется и скачается несколько минут, но это же хорошо, можно идти пить кофе, думать о дальнейших действиях по проекту или почитать хабр, наконец )
>Извините, я не понял зачем ломать валидатор ради edit in place
А никто его не ломает, он сам ломается) при чем тут edit in place? Конечно же можно вырезать эти атрибуты в режиме обычного посетителя, но это сразу минус производительности. Я бы рекомендовал юми сделать настройку, чтобы они вырезались простейшей регуляркой для тех кому это важно.
>jQuery использует свои атрибуты вопреки стандарту. Но делает это в динамике.
Нет, не вопреки, а именно ПО стандарту. И да, валидатор забивает на динамику и это опять же не правильно с его стороны. Т.е. если страница, которая проходит валидацию после отработки динамики не валидна, то грош цена такой «валидной» верстке.
На практике, конечно, такое не всегда возможно, но зависимости модулей можно учитывать.
Например, изменения в компонентах, связанных с правами доступа (самое «ядерное» ядро) должны быть протестированы все модули, которые от него зависят — то есть практически вся система.
А если вся команда «пилила» лишь функционал интернет магазина, то нет смысла (да и времени) тестировать модуль «Обратная связь».
А вообще, в основной чеклист может быть занесено по одному — два не сложных теста каждого модуля, чтобы тестировщик хотя бы зашел в них и проверил живые ли они.
Очень печально что далеко не все тестировщики уделяют время на собственное развитие.
Чтобы быть хорошим тестировщиком (ИМХО), надо иметь особый склад ума и характера и любить свою работу, постоянно изучая специалзированную литературу самостоятельно.
Из своих знакомых я знаю только одного человека, которому действительно нравится тестирование и который посещает кучу конференций и растет профессионально. А так же знаю пару человек, кто в прямую говорят что занимается этим временно, и на самом деле это не особо интересно.
Ну и должен быть глобальный чек-лист, который проверяется для КАЖДОГО релиза. Там должен быть самый главный и важный функционал, который ни в коем случае не должен сломаться.
Если рассматривать что все-таки в рамках одного скрипта возможны одинаковые запросы. Например, если мы обновляем что-то на сайте и запускаем типовые INSERT/UPDATE.
PS. спасибо за статью
крастьсписывать деньги абонентов?На практике еще никогда не возникало желания и необходимости тестировать приватные методы. На мой взгляд, в этом случае явный признак — проблема в архитектуре.
Надо, через тесты на публичные методы конкретных реализаций класса
>Абсолютно всё то же самое актуально и для публичных методов и даже для целых классов.
Опубликованные методы и классы не так просто выпилить, особенно если ты не владеешь всем кодом проекта и публикуешь API. Тут поможет только deprecated и делегирование
Ну да, спорить не буду, рефакторинг он разный… )
Конечно, ибо эти методы относятся только к нему и актуальны только для него. У наследника доступа нет, но есть своя реализация и приватные методы, ему нет дела до приватных методов своего родителя, потому что они его не касаются.
>А если я напишу приватную функцию вычисления синуса?
Раз она приватная, значит она нужна (касается) только для этого класса и он ее использует для своей реализации. Лучше протестировать то, для чего она используется. Завтра синус менеджеры заменят на косинус и в чем смысл теста?)
При рефакторинге кода, написанные тесты на приватные методы составят незабываемое «удовольствие». Простейшее перемещение или изменение сигнатуры приватного метода доставит еще и кучу проблем с его тестами. В итоге, они просто будут скорее всего удалены, либо рефакторинг отложен со словами «ну вот, покрыл тестами, работает, да ну и фиг с ним, с дублированием кода».
Приватные методы они на то и приватные, что в любой момент могут быть удалены, переписаны, дополнены, перемещены, раздроблены на более мелкие части. Если проект развивается здоровым путем, то это для него нормальная практика.
Человеку, который собрал отличную команду из фриласеров — двойное уважение на мой взгляд.
PS. зависть, плохое чувство.
Интересно, а у себя то они его отключили, а то я смотрю такие настройки апача www.xforge.ru/images/ они не считают опасными )
«Памятка системному администратору по вопросам профилактики от вирусов и паразитического софта:
— Обязательное отключение поддержки PHP на Ваших серверах и зонах хост-провайдеров.
Помните, что только при поддержке PHP можно извне завести Вам зловредный код без Вашей воли при неизвестных злоумышленику параметрах доступа по FTP»
Так в этом файле даже переносы строк были аккуратнее расставлены, чем в оригинальном ))))
Если кому-то понадобится очень, все равно напишет деобфускатор. А какой ущерб производительности от такой обфускации — вообще жесть, одни евалы чего стоят.
У меня была задача сделать код проекта не читаемым. Долго искал обфускаторы php-кода, все слишком навороченные и многие просто не работают в режиме, когда есть часть кода обфусциорваная, а часть нет. В итоге, написал сам из 100 строчек, используя php-токинайзер и md5.
Всем хочется, чтобы важные именно для него баги были поправлены в кратчайшие сроки, но вы же, как разработчик системы должны прекрасно понимать, что приоритеты такие приоритеты…
А никто его не ломает, он сам ломается) при чем тут edit in place? Конечно же можно вырезать эти атрибуты в режиме обычного посетителя, но это сразу минус производительности. Я бы рекомендовал юми сделать настройку, чтобы они вырезались простейшей регуляркой для тех кому это важно.
>jQuery использует свои атрибуты вопреки стандарту. Но делает это в динамике.
Нет, не вопреки, а именно ПО стандарту. И да, валидатор забивает на динамику и это опять же не правильно с его стороны. Т.е. если страница, которая проходит валидацию после отработки динамики не валидна, то грош цена такой «валидной» верстке.