When doing integration testing via JS tests, various tests should apply to all cluster server parameters. To centralize test efforts, there is a JS tests library jstests/libs/cluster_server_parameter_utils.js that supports a dozen of individual tests. That JS test library contains a listing of the cluster server parameters. This listing also contains a series of fields (featureFlag, setParameters, serverless, standaloneIncompatible) that determine which parameters are available (and thus should be considered for testing) according to the server environment used in the tests.

Inspecting the code for considering which cluster server parameters should be tested hints to some likely flaws:

• The validateSetParameter function tests if a given server parameter is set by running db.runCommand({getParameter: 1, param: 1}). This will try to find a server parameter literally called "param", and thus the check always fails and cluster server parameters with a setParameters field are never considered. Most likely db.runCommand({getParameter: 1, [param]: 1}) was intended.

• The validateStandalone function checks if the parameter definition has a standaloneIncompatible field, but never checks whether its value is true or false. Thus, cluster server parameters defined with a standaloneIncompatible: false field will still not be tested in standalone server instances. This appears to be undesired (e.g. see SERVER-79236). The final check should be most likely be !(isStandalone && cp.standaloneIncompatible).

Review the elegibility logic in order to increase test coverage.