Local Development
The local development strategy should work only on the MFe we want to use and everything else (the MFe, parcel, or utility) in its deployed versions. There could be two approaches. One is to use the tool import-map-overrides. This will allow you to switch to the local or deployed version immediately. It will also be helpful to perform testing.
The other approach is to use a stand-alone method. This will require using the root config locally. The better approach is to use the import-map-overrides as it provides the complete prod-like experience to the developer.
Testing
Performing unit or end-to-end testing is similar to testing any other front-end application with some exceptions.
Unit Testing
Everything else is similar to a unit test of applications, parcels, or utility except for two points. One is when an MFe is imported to another MFe application because the unit test is usually performed locally, and there we will not have access to other MFe. The solution is to mock the other MFe. The second exception is when system.import is used to load another MFe asynchronously.
Here, we need to again mock the SystemJS and imported modules. The point to be noted is that system.import returns a promise, meaning the tested area would be asynchronous and wait to resolve the promise.
E2E Testing
There are two possible approaches to performing e2e testing. One is to test the application as a stand-alone. With this, the root config cannot be tested properly if some initialization or configuration has been done at this level. In this case, it is better to mock the root config for one application only.
The other e2e testing approach is to test everything else together. In this case, the configuration would be the same as a prod environment. In this case, a tool called import-map-overrides provided by the single-SAP could be useful.