As @DerekF said in his answer, custom settings are data and so need to be created in the context of unit tests.
However, what Derek didn't mention is that if you do this, and actually commit custom settings instances to the database, you will run into database locking problems if you run unit tests in parallel where the same instances are created in the database by different unit tests. This happens even though Salesforce is supposed to provide isolated databases to each separate unit test. While the data itself is only visible in a given unit test, there is still contention in the over-all database during such conflicting instance creations.
I recommend, therefore, that you either:
- follow Derek's suggestion and switch to Custom Metadata Type instances; the downside here is that your unit tests become dependent on external data unless you provide a separate mechanism in your unit testing to mock out these instances OR
- refactor your application logic to use a single source of custom settings instances - e.g. a Settings class with methods to access your various types of custom settings. This class can be written to locally cache the custom settings instances returned to the code, which allows your unit tests to fetch the instance first, set the required values in the settings fields, and then rely on the production code under test to retrieve this same cached instance through this class and therefore see the correct settings for the test, all without ever saving the instance to the database.
Either way, you have some infrastructure/plumbing code to add to let you do this cleanly.