This is something I encounter in every project: I make some functionality for myself as developer – test functionality, delete all records from tables, you name it – and that functionality should never make it into production. My usual tactic is to create a branch line for every release to production, and to delete all test functionality from there. The test functionality is put into its own module and I simply delete that module and remove buttons from the UI.

If you have written extensive unit tests, you can follow a similar strategy, but you may not want to delete the tests: if you fix a bug in this branch line for production, I imagine you want to run your unit tests as well. A solution could be to restrict access to the unit testing module (its pages and microflow) to a ‘developer’ user role that only developers have. Your test code is still deployed to production, but only developers can access it.

An alternative strategy is ensure test code is never run in production. You could start every unit test you create with a validation that the environment the test is being executed in is not production. You could implement this by adding a constant to your model which you set to the corresponding environment (e.g. an IsProduction environment constant, which you set to true for your production environment) or you could retrieve the URL of the application by using CommunityCommons.GetApplicationURL and check if the url contains ‘test’ or ‘accp’ and only run the tests if this is the case.

AFAIK this is not possible. Tests are deployed together with the rest of your code on all environments.
However, as long as you do not run them manually there should be no harm in having them there.