gz0t

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

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

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

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

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

Довольно долго работаю как (удаленный) консультант по ML. Это возможно, просто пробуйте.

Где искать, мой опыт:
- первого заказчика нашел на odesk
- второго - в треде 'who is hiring' на hackernews
остальные приходили по рекомендациям

Несколько трюков:
- делайте бесплатный простой прототип. Простой работающий классификатор/регрессию без оптимизаций можно сделать за пару часов. А для клиента это будет 50-70% решения задачи.
- шлите резюме даже туда, где не думают о фрилансе или удаленной работе. Если вы хорошо делаете свою работу, им абсолютно без разницы где вы находитесь.
- учите английский. Иногда это важней, чем ваши основные скилы в ML.

Плюсы удаленной работы:
- если сравнивать с нашими конторами (mail.ru, yandex), можно выйти на гораздо более высокую зарплату.
- все заказчкики, с кем я работал, устраивали мне бесплатные поездки on-site. К примеру, так я побывал в Штатах, Ирландии, Сербии, Австрии
- меньше долбят с проблемами, не имеющими отношения к ML

Минусы:
- если ты один специалист в команде, часто не с кем обсудить текущие задачи. Если постоянно не учиться, начнете деградировать.
- сложней коммуникации. Разница во времени. Но это общие проблемы удаленки.

ps не читайте предыдущих комментаторов :)
pps мне так часто задают этот вопрос, что начинаю задумываться о создании специализированного сервиса по поиску удаленных data scientist'ов