I was facing a similar situation where my unit tests were unable to access the app.config and the appropriate "appSettings" section. In my case, the solution mentioned above loading the OpenMappedMachineConfiguration doesn't work because it didn't know how to cast the AppSettings section, thinking it was a machine config file rather than a normal application config file.
To explicitly load a file for an application expecting the "appSettings" section, this method works better:
Configuration configuration = System.Configuration.ConfigurationManager.OpenExeConfiguration("./App.exe");
string value = configuration.AppSettings.Settings["test"].Value;
By specifying the application name, it automatically adds the suffix ".config" like "App.exe.config", which is the name of the generated file. This approach of loading configuration is useful when you want to explicitly load a separate config, such as from a linked application.
However, in my case, I also noticed that just by removing the existing configs and readding them as you did originally (add -> new Item -> select Application Configuration File), the file would then properly generate the [AppName].dll.config relative to the test project assembly, which appears to be why yours started working after that, because the file was not in the bin/Debug folder with the proper naming convention. Once the file is being generated properly in the output directory, the normal syntax begins working again:
string test = ConfigurationManager.AppSettings["test"];
It's not clear why the file did not originally generate properly and it began relying upon a "Microsoft Visual Studio\2019\Enterprise\Common7\IDE\Extensions\TestPlatform\testhost.net462.x86.exe.config" file instead.
Perhaps, it wasn't actually in the output directory at the time it was added to the project and the test was run. This appears to be a bug in Visual Studio where it fails to regenerate the missing config file if it was missing and the application itself hasn't changed. I could reproduce this issue, by manually deleting just the [App].dll.config file from bin/debug and rerunning the test. Even building the project over again does not regenerate the .config file. To regenerate it, I had to explicitly run the "Rebuild" option, but how we ran into this bug isn't clear at this time.