What is your unit test actually trying to test?
- If bool.TryParse works as intended?
- If ConfigurationManager.AppSetting works as intended and loads the config file?
- If the actual configuration file has a "isFlag" value that can be parsed as a boolean?
In the first case you could just test bool.TryParse
directly, or make an extension, bool AsBool(this NameValueCollection self, string key) ...
to provide a more convenient access + parsing.
The second case would probably not be very meaningful since the functionality is provided by the framework, but it should be possible to setup the build to provide the unit test with a configuration file with some test data.
In the third case you need an actual config file to load, so it will probably be more cumbersome to test, but might also give more value if you can detect that someone wrote "troe" instead of "true".
Keep in mind that unit tests should provide value. In my experience unit testing of very simple methods, or methods involving lots of dependencies, tend to provide lower value than highly complex methods with few dependencies. I would recommend against dogmatic rules like "all methods must be unit tested".