Иван Батурин

1. Практически на любом современном десктопном CPU достаточно ядер для тестирования и отладки разного рода параллельных алгоритмов. Поэтому предлагать взять "побольше" смысла не вижу. Меньше двух вы не найдёте, больше восьми не так уж и нужно.
   
2. Тактовой частоты любого из современных CPU дороже 15 тыщ достаточно для комфортной разработки, если речь идёт об IDE, редакторе, отладке.
   
3. Обе указанные характеристики в целом имеют очень небольшое значение. Архитектура, рыночный сегмент и поколение процессора (или проще - год выпуска) куда важнее, чем тактовая частота или количество ядер.
   
4. Production-железо - совсем другое дело. Есть задачи которые плохо параллелятся, есть - которые хорошо. Сервера последние лет 10 идут на повышение количества ядер и повышение плотности. Но вам-то зачем об этом беспокоиться?
   
5. Мне кажется, вы ещё не уверены, чем вообще будете заниматься, но железо хотите купить сейчас под какие-то непонятные "сферы разработки". Лучше купите чего-нибудь послабее - чтобы не забывать о производительности того, что вы пишете.
   

А вот оперативной памяти много не бывает, эт да. Пихайте сколько влезет. Диск тоже можно побыстрее - нередко у разработчика различные процессы (сборка, установка зависимостей и т.д.) именно в диск и упираются.
Ответ написан с предположением что речь идёт о персональной ЭВМ для разработчика.

Я не люблю поднимать тяжести, но могу. Я не люблю писать тесты, но пишу. Мне не интересен был учебник по налогообложению, но я его прочитал. Я интроверт и мизантроп, но это не помешало мне дорасти до должности директора по ИТ, 13 лет руководить людьми и делать это хорошо. Особенности характера - это не приговор и даже не всегда препятствие. Даже аутисты умудряются интегрироваться в общество. Нужно просто делать то, что ведёт тебя к успеху. Или признаться себе в том, что ты безвольный нытик и твой удел - прозябание.

Можете скопировать регулярку на сервис https://regex101.com/, там есть вкладка explanation, которая описывает по частям, как она работает

Юнит-тест:
Юнит-тест невозможен в данном случае, тк нет этого самого юнита в виде чистой функции (без побочных эффектов). Тут сплошной сайд-эффект: отправка на SMTP, прослушивание HTTP, то есть особо не потестируешь юнитами.
Объектом тестирования юнит-тестом служит или функция или объект. А у вас и нет ни функции/процедуры даже хотя бы.

Это будет функциональный (если будете из кода вызывать) или приемочный (если свое приложение через HTTP дергать) в любом случае.

Как по итогу все же протестировать:
Такой функционал обычно тестируют так:

• для начала настройки отправки почты переносят в конфиг
  
• в тестовом окружении в конфиг подсовывают настройки своего SMTP сервера
  
• поднимают фейковый почтовый сервер, например Mailhog на Go (очень легко ставится)
  
• выполняют работу скрипта, чтобы почта ушла, почта летит на ваш подмененный сервер, и у него через АПИ проверяют, что письмо пришло
  

Если возьмете Codeception, установите Mailhog на машину, где будут гоняться тесты, или докер-контейнер (вообще парой строк, например если в Gitlab CI гоняете), и поставите модуль Codeception + Mailhog. То легко все проделаете.