Судя по контексту, Вас интересует анонимность, а не безопасность.

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

Именно от имени этой личности Вы будете выкладывать в сеть всю необходимую информацию — имя и контактную информацию для клиентов/знакомых, адрес и кредитку для магазинов, фотки для друзей. Вы можете пытаться контролировать объём выкладываемой информации, ограничивать своё присутствие в социальных сетях, и т.д. — но это не даст большого эффекта: всё, что Вы не расскажете про себя сами, про Вас расскажут Ваши друзья. Избежать этого можно, только если у Вас нет друзей, Вы не делаете покупки в интернете, не ищете через интернет работу, не пытаетесь заработать деньги через интернет, … что для большинства абсолютно неприемлемо, так что лучше сразу смиритесь с тем, что «реальный» виртуал у Вас всё-равно будет. Единственный возможный способ его «анонимизировать» это не привлекать к нему внимания — сделайте так, чтобы эта «реальная» виртуальная личность абсолютно ничем не выделялась на общем фоне, будьте «как все».

А для всей остальной деятельности в сети используйте совершенно другие виртуальные личности. Чтобы их не смогли связать с Вашей реальной личностью, желательно исключить все возможные пересечения виртуальных личностей с реальной:

1. придумайте полноценную личность — имя, ник, пол, email, …
2. используйте для всей деятельности от имени виртуала другую OS (в идеале не просто ещё одну винду/линух в VMware, а действительно иную OS, с другим набором используемых приложений — другой браузер, IM-клиент, etc.); может иметь смысл использовать специальные дистрибутивы линуха ориентированные на максимальную анонимность
3. настройте эту OS не так, как обычно настраиваете свою систему — другой язык, другое разрешение экрана, другая тайм-зона
4. по возможности используйте другой канал для выхода в инет (напр. если основная система работает через городскую локалку или ADSL, виртуальная система может работать через публичный WiFi)

И только когда эта часть Вашей анонимизации готова, можете начинать заботиться о VPN, Tor и proxy. Конечно, ещё остаётся вероятность, что Вас всё-равно вычислят по психологическому профилю… :-) но чтобы кто-то начал сравнивать псих.профили Ваших виртуалов сначала должно появиться подозрение, что эти виртуалы принадлежат одному человеку, а для этого скорее всего Вам необходимо будет самостоятельно проговориться или ошибиться (указать не тот email, или выйти в инет не через тот канал, etc.).

DISCLAIMER: Поддержка полноценной не отслеживаемой виртуальной личности может со временем привести к психическому заболеванию. :)

Мне в своё время очень помогла разобраться с тестированием книжка Perl Testing: A Developer's Notebook. В подходе к тестированию особой разницы между Perl и PHP нет, так что Вам она тоже может оказаться полезна. Перевода, к сожалению, я по-быстрому не нашёл, возможно она есть только на английском.

При тестировании один из ключевых моментов — нужно постоянно очень хорошо отдавать себе отчёт в том, что именно мы сейчас тестируем. А тестируем мы обычно наш код, а не окружающую среду (вроде базы данных) — в тестах мы предполагаем, что база данных работает корректно, вопрос в том, корректно ли наш код работает с базой данных. Поэтому, да, можно тестировать работу с базой даже без самой базы — mock-нув функции отправляющие SQL-запросы в базу, и в тесте проверяя, что наш код генерирует именно те SQL-запросы, в том порядке и с теми значениями, которые он должен был сгенерировать (а заодно и подставляя тестируемому коду нужные нам данные под видом «ответа от базы на SQL-запрос»). И да, на реальной базе данных этот код может не работать корректно, не смотря на то, что тесты он проходит — просто потому, что он генерирует не те SQL-запросы, которые нужно генерировать для этого сервера БД. Но это не имеет отношения к тестам — они свою работу выполнили: подтвердили, что код работает именно так, как ожидается. А если задача была поставлена неверно, и код должен делать что-то другое — это проблема постановки задачи, а не тестирования.

Барабашка портящий базу — это не проблема тестирования кода. Хотите написать тест против барабашек — сравнивайте в тесте схему базы с эталонной, и правьте тест после любого изменения схемы базы. Но смысла в этом нет.

Совместимость фикстур из тестов с текущей схемой базы проверить очень просто: при запуске теста создавайте тестовую базу данных используя текущую схему основной базы данных, а в фикстурах храните только данные, без схемы таблиц.

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

Только что ещё раз просмотрел эту статью и комментарии в кеше гугла — в упор не вижу нарушений каких либо правил хабра. Интересно, кстати, попадает ли попытка понять, какое именно правило хабра было нарушено автором этой статьи под правило «запрещено обсуждать правила сайта и действия администрации, направленные на их соблюдение».

Прошу прощения, я не знаю «что можно» и «что нельзя» делать в потоках третьего питона, но раз за двое суток по теме никто не ответил, я отвечу немного не по теме.

Я бы порекомендовал вместо поисков «что можно» и «что нельзя» изучить «как надо» работать с потоками вообще. А потом, уже понимая что Вы хотите получить, изучать как именно нечто подобное можно сделать в третьем питоне. А «надо» с потоками работать в стиле CSP — это самый простой подход, превращающий многопоточное программирование из очень сложной, запутанной и глючной. К сожалению, он подразумевает использование действительно большого количества потоков, что невозможно если каждому потоку выделять довольно большой стек (что делают практически все реализации потоков в разных языках и ОС). Поэтому «пощупать» это можно, например, на языке Go, или на stackless питоне.