To develop and test Feature Parameters with Managed 2GP (Second-Generation Managed Packages), you must work directly with the Feature Parameter metadata.
With that in mind, here are the answers to your specific questions.
How do I test FMA parameters?
This depends on whether you’re trying to do functional or integration tests.
For functional tests, you can manually change the FP (Feature Parameter) metadata as you develop in a namespaced scratch org. This will let you see how your code reacts to changes in Feature Parameter values.
Just make sure that you know what your “baseline” FP values should be so you don’t unintentionally pollute your published package versions with dev/test default values. Better yet, use source control and just discard your dev/test changes before publishing a package version.
For integration tests, ie. when you want to see how a change in a Subscriber-to-LMO FP might trigger some custom code running in your LMO, the only option is to create a managed-released package version and then install that package in an org.
Remember, you can’t do integration tests with managed-beta packages because the LMO/Subscriber connections aren’t wired up as part of beta package installs.
Do Feature Parameters exist in scratch orgs?
If you’re using a namespaced scratch org, they exist as if you were developing directly in a packaging org. If you’re looking for an LMO/Subscriber connection, though, you’ll need to build a managed-released package version and then install that package in the scratch org.
Do you need to mock Feature Parameters?
You shouldn’t need to mock Feature Parameters. They exist as metadata while you’re developing your packaged code. If you’re developing in a namespaced scratch org, the FP metadata will be deployed to your scratch org as part of your initial
However, if you build complex logic into your app that relies on certain Feature Parameter values, you may need to get creative in your test code to ensure that all logical paths are taken.