nonlux

Ну тесты бываю разными: и зелеными и красными. ))

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

Я как ярый сторонник BDD использую два типа тестов feature (читай интеграционные тесты) и spec (читай юнит тесты)

Итак, features. Берем Behat и херачем кучу тестов по типу:
Зашел на главную,
Потыкал чего-то в форме регистрации
Зашел в профиль и увидел свое имя и фотку на странице
Profit!

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

Для таких тестов хорошо иметь поддержку окружения (prodaction, development, test) в коде, чтобы например можно было капчу отключить или еще какую сложную лабуду не делать.
Если система замудрена до ужаса придется здесь для тестов все окружение поднимать. А лучще вообще отдать CI такое делать пусть друг трудится.
Плюс таких тестов например когда пишем сложный фронт - сложный бек и еще более сложнейший бек-бек, то можно одним чохом протестировать работу всего сервиса.

Следующий уровень абстракции spec:

Если нам в интеграционных тестах было немного пофиг на БД. Она как бы пишет, но что так за структура абсолютно пофиг. То в случае со спекими нам ВАЩЕ ПОФИГ.
Мы берем наш класс (функцию) и проверяем что за результаты она отдает. Вместо объектов, с которыми подопытный (объект тестируемого класса), даем ему резиновую бабу (моки и т.п), и смотрим на результаты нашего труда.

Главное при том и другом подходе нам без разницы, что у нас в кишках мы всегда тестируем публичные свойства системы. В первом случае это реакция на пользователя, во втором публичное API класса.

Вот как то так!

P.S тесты надо бы писать до кода.

в nginx никак
в php.ini
php.net/manual/ru/errorfunc.configuration.php#ini....

а вообще это плохо, лучше это устанять

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

1. docker-окружение
(в 90% случаев для веб-разработки достаточно php -S 0.0.0.0:8000)
виртуальные машину становятся нужны:
- когда надоест переустанавливать хост-систему из-за обилия хлама
- когда работаешь с несколькими проектами имеющие специфические (разные) настройки окружения(php, web-сервер, база)
- когда надоест решать проблемы в команде из-за того что по разному настроено окружение

2. git - система контроля версий
Помнить что ты и когда изменял, должен не человек, а машина.
Это необходимо:
- чтобы не испортить всю работы за прошедший год нажав del
- чтобы определить кто из команды злодей и все испортил
- чтобы не думать как перенести свежую версию проекта с одной машины на другую

3. composer - пакетный менеджер для php
Нужно, когда лениво помнить все ссылки на все php библиотеки, самому качать их, подключать в автозагрузку

4. behat + phpspec
Тесты нужны:
- когда хочется почувствовать себя безопасности и для сладко спать ночь, забыв о кошмарах о сломанном коде
- когда в production все снова сломалось
- когда ты написал одну новую фичу, а сломал три

5. zsh
Хорошей консолью приятно пользоваться, работа идет быстрее.
Консоль есть жизнь, жизнь есть shell.

6. tmux
Мало одно окошка в консоли, тогда tmux идет к вам.
В качестве бонуса получите возможность парного программирования совершенно бесплатно

7. tmuxinator
Надоело каждый раз открывать кучу окон для tmux, попробуйте его )
8. vim
- Потянуло на что-нибудь необычное?
- Хочется эффективнее писать код ?
Ну что открыли vim? В первый раз? Поздравляю закрыть вы его не сможете )
Вызывает зависимость при частом потреблении

9. continuous integration сервер
Вообще ci сервер это одушевленная машина. Это твой тамагочи, ты кормишь его хорошим кодом, он радуется и ты видишь приятный зеленый огонек. Если ты дал с код от скажет что не вкусно. Ну а если ты ему, что гнилое он будет долго на тебя орать плохими словами. Со временем он растет и учится делать более серьезные вещи, и начнет помогать тебе:
Его скилы:
- он может сам выполнить 10 минутные тесты
- подготовить и опубликовать проект
- рассказать о твоем коде, даже то что ты не знаешь
Он легко обучается и ты легко сможешь научить его удивительным вещам.

10. куча линтеров на pre commit hook
Чтобы ci не кормить плохими продуктами, хорошо бы проверять что ты сделал до отправки на сервер. Что бы не забыть это сделать git сам работу.

11. gulp
gulp - это еще один твой помощник.
как если использовать, как watcher файлов + livepreview, можно забыть о F5 в браузере

12. bower
Тоже что и composer но для управления ассетами. Это я о всяких jQuery и Bootstrap

666. Линукс
Даже если не хочется ставить как хост-систему, его все равно надо знать. Ваш код будет работать на нем )

Алексей Уколов +1
Проведем аналогию с идеализированным алгоритмом работы ФСТЭК для лицензии ПО с гос. тайной
1. Берется определенная версия ПО
2. Проводится полный аудит кода
3. Данная версия ПО получает лицензию

Но подумайте о том, что бы работать на ПЭВМ в гос тайной надо проверить весь стек ПО

Поэтому просто забейте на эту параною.
Подумайте:
1. веб-сервер, php, git делают одни люди
2. Вторые люди собирают это под ту ос, что вы используете
3. Администраторы железа на вашем хостинге - это третьи люди
4. Администраторы магистральной сети - это четвертые

Враги кругом.
Вы можете делать аудит всего стороннего кода, но у вас больше шансов написать огромную дыру в вашем приложении, где любой пользователь сделает rm -fr.

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

Melkij +1
родительский класс не будет видеть private метод объявленные в наследниках.
На пальцах ООП тут работает так:
Catalog->__toString() на сам деле работает так Catalog::parent->__toString() (т.е функция вызывается в контексте Table)
Если уж очень хочется именно через get_object_vars, то он должен вызываться у наследников. Как вашем комментарии или так:

<?php                                                                                                                                                                                       
                                                                                     
  class Catalog extends Table {                                                      
    private $type;                                                                   
    private $desc;                                                                   
    protected $prot;                                                                 
    public $pub;                                                                     
                                                                                     
    protected function getMetods() {                                                 
      $vars = get_object_vars($this->self);                                          
      return array_keys($vars);                                                      
    }                                                                                
                                                                                     
  }                                                                                  
                                                                                     
  abstract class Table {                                                             
    public $perPub;                                                                  
    protected $perProt;                                                              
    private $perPriv;                                                                
    protected $self;                                                                 
    abstract protected function getMetods();                                         
    public function __toString() {                                                   
      return implode(', ', $this->getMetods());                                      
    }                                                                                
  }                                                                                  
                                                                                     
  $o=new Catalog();                                                                  
                                                                                     
  echo (string) $o;

Зачем IDE это делать, когда есть нормальные утилиты?

Вообще гугл все рассказывает: например вот исходники одного проекта: https://github.com/352Media/skilltree
Но я не думаю что это тривиальная задача.
Что бы было все красиво, с урл и всякими плюхами удобнее всего пользоваться всякими фреймворками, типа backbone knockout и т.д.

) symfony.com/doc/current/book/security.html

Почитал все вопросы ответы по теме.
По моему в целом проблема высосана из пальца, но сейчас не об этом.

1. Не понятно для кого это делается. Просто для себя или будут пользователи у вашего решения.
Если наберется с N пользователей, то не померет ли ваш белый сервер от постоянной перезагрузки страниц (DDos).

2. аналогично первому только касаемо базы и прочих ресурсов на сервере. Хостинг провайдер не пошлет за постоянной превышение нагрузки?

3 Черный ящик php. Я не могу посоветовать решения не зная, как урезан php на белом хостинге.

4. Ближе к телу. Думаю на ваших серверах все реализована так:
Запрос -> веб сервер (apache, nginx) -> php ( fpm, cgi)

Все они созданы, чтобы сдохнуть ( т.е как у веб сервера так и php есть настройки времени жизни для запроса) и соответственно бесконечных одиночных запросов в этом контексте ( для http) быть не может.

Люди уже давно придумали как это обойти : long pooling, web sockets. Даже придумали php, который не умирает (Reactphp).

Но возможны ли эти решения для вас, зависит от п.п 3 ( см. выше)

5.

Может ли php получать и обрабатывать часть информации? (Так как один ответ сервера длится бесконечно и его, естественно надо обрабатывать частями).
Может ли php отправлять информацию частями? (Поподробнее про буферизацию, пожалуйста).

Извините, ерунда. см п.п.4
Правильным решением будет 100 разных POST отправить с серого к белому серверу. На белом все собрать в кучу.

6. В целом, если вам необходима только выдача данных от серого сервера. То самым простым будет реализация своего static http proxy.
Т.е. серый генерирует уже готовые страницы отдает их белому. А тот их сохраняет и выдает. Если пользователь запросит, то что серый еще не обработал слать его на ... (404)

1. Да я бы мокнул ), но для этого конструктор надо поменять.
2. Думаю тут ноги пляшут от настроек PHP.
Посмотрите в каком окружении работает ваш (php.ini) Main и в каком работает phpunit.
Если мои телепатические способности не подводят. То ваш Main работает с веб-окружением ( php-fpm или cgi и т.д.), а phpunit работает через php-cli. Вся разница в используемом php.ini
И скорее всего во втором не подключено ваше расширение
3. Хз, все зависит от логики приложения