Most applications will require some external configuration; you can hide this by making it dependent on magic variables, or by saving it to some internal location, but that won't remove the need. The goal is to recognize what should be external, and what can be internal. Only the internal parts can be tested.
An application should not trust an external configuration file to be correct. It should check the correctness, and report errors. If it is not possible for the application to check the configuration file, you are probably doing too much with it. If the configuration file changes the behavior of the application, it shouldn't be external in my opinion.
For example, a database username/password can be easily verified by the application by trying to connect to the database. If this fails, it can report it, and it is obviously not a bug in the application code. Similarly, for a file path the existence and access rights can be checked.
Now, if you were to put SQL queries in the configuration file, then the application cannot easily check the correctness of those queries. The same goes for a full dependency-injection specification (a la Java-Spring XML) file. Those should not be in external configuration files.
But if the specified configuration describes something external, and you can quickly check its correctness, I don't think there is anything wrong with external configuration files.
Edit: also make sure your error reports show which configuration file is used. Nothing is more frustrating than finding out you were looking at the wrong file after hours of trying to find out what's wrong with it.