Is there a good way to manage running multiple arb

Question

When I'm prototyping/testing/experimenting/benchmarking with C# in Visual Studio (I've also recently started using Visual Studio code and am doing much the same thing) I used to abuse Unit Testing by doing stuff like this:

public class Blah
{
    [Test]  public void create_db() { ... }
    [Test]  public void populate_large_dataset() { ... }
    [Test]  public void populate_small_dataset() { ... }
    [Test]  public void mutate_data_method1() { ... }
    [Test]  public void mutate_data_method2() { ... }
    [Test]  public void mutate_data_method3() { ... }
    [Test]  public void benchmark_1() { ... }
    [Test]  public void benchmark_2() { ... }
}

This is a specific example related to recent jobs but historically I've found this sort of workflow has been conducive in areas where I'm doing things in the prototype/proof-of-concept stage. The basic idea was I had a bunch of entry points which are basically methods and it is relatively easy for me to select and arbitrarily run one - either via hotkeys or within a 1-2 clicks via the Resharper (or Visual Studio xUnit? or Visual Studio Code .NET Core Test Explorer) Unit Test Explorer.

I know this is mis-use but so far in all my searching I haven't found a better alternative, which suggests I'm probably not searching for the right terms as it's hard to imagine I'm alone in doing this sort of thing.

In VSCode (which I am admnittedly very new to), this seems to to be particularly problematic as VSCode continually gets itself into a very confused state (remnants of tests seem to have a tendency to run in the background and stay alive, despite not giving the impression that they are doing so. This is probably very reasonable behaviour if I wasn't abusing it the way I was). This has become enough of a pain point I'd like to know what I should be doing.

The possible alternatives I've considered are:

• Creating multiple projects, one each to represent each entry point - this seems spectacularly heavy handed and painfully cumbersome
• Have a single main method and every time I want to run a different function I edit this to call the appropriate method - also quite cumbersome
• Edit csproj to have a bunch of different targets that run
  • Again, cumbersome
• DIY - write my own UI / CLI to do this
  • Seems like a fair bit of work to do it correctly. I feel like I'd basically be rewriting the unit test runners, of which there is a LOT going on behind the scenes.

My ideal workflow is:

• Create a method in my code (some sort of public static void Foo())
• Be able to run that with a point and click or hotkey, similar to how unit tests are done. Similar rules regarding error handling would be done (for e.g. if the method isn't static then I'd expect it to try to instantiate an instance of the containing class but fail if it can't, or error if the method takes arguments)

I DON'T want to have jump to other files to write a bunch of anciliary code that basically provides references and call points to Foo(), which I'd have to update if I rename or delete Foo().

What is 'best practice' here? Am I thinking about this the wrong way? Am I developing in the wrong manner?