Константин Китманов

Для юнит-тестов советую посмотреть tape (+ nyc, какой смысл в тестах без покрытия), вот хорошая статья: «Why I use Tape Instead of Mocha &So Should You».

метод init() вызывается вообще в совершенно другом месте

Тестами можно покрыть только то, что имеет явное и воспроизводимое состояние.

Как мне сделать фейковый класс Settings, что бы в тестируемом методе значение переменной обращалось бралось из свойства фекового класса?

Никак. В момент объявления функции, которая использует Settings, происходит замыкание, и в функции сохраняется ссылка именно на то значение внешней переменной Settings, которое было на момент объявления. Это можно обойти, но я вам не скажу, как, а то вы такого наворотите, что мама дорогая:)

Но вообще какая-то странная у вас архитектура. Класс, у которого есть статический метод init — это очень странно пахнет. Синглтон, что ли? Если да, то бросьте бяку.

У вас в тегах стоит unit-тесты — так вот это как раз автоматизированное тестирование: Кто должен писать юнит-тесты?

Есть много разных автоматизированных тестов.

Юнит-тесты пишет разработчик (в идеале — тот же самый, который пишет код, покрытый этими тестами, и ДО написания кода). Юнит-тесты помогают удостовериться, что каждый отдельный кусок (поэтому — unit) в программе по отдельности работает корректно. Имея на руках рабочие юнит-тесты, можно спокойно делать рефакторинг.

Интеграционные тесты помогают удостовериться, что и в совокупности все эти куски выдают осмысленные результаты. Из этих тестов становится понятно, что на сайт можно залогиниться, а софтина пишет в файл в корректном формате. Их тоже часто пишут программисты.

Приемочные тесты помогают удостовериться, что программа соответстует требованиям, заложенным в ТЗ/диздок.
Регрессионные тесты — что после последнего обновления ничего не сломалось. Эти два последних делают тестеры, с помощью различных тулзов — для веба, например, это Selenium.

Все эти тесты, в идеале, запускаются на каждый коммит на специальном Continuos Integration сервере, и если программист «опять накодил в углу», ему приходит письмо, что его код не прошел такой-то тест и это надо починить.

Посмотрите, как сделано в тестах node-express-mongoose-demo. Там, правда, скорее интеграционные тесты, а не юнит, но смысл тот же и проверяется примерно то же самое.

Небольшой проект с юнит-тестами, в package.json видно, как они запускаются, а в папке test собственно тесты.