Utility Class within an Automated Testing Project - Static, Singleton, or Other Design?

I've searched quite a bit about this on stack overflow and think this question is different enough to merit a new question.

For integration tests, I need to enable the Distributed Transaction Coordinator service (SQL Server) so that I can use the database rollback feature of MSTestExtensions.

So I need methods like as follows:

public void StartService(s开发者_如何学Ctring serviceName)
public void StopService(string serviceName)
public void RestartService(string serviceName)

It would be very easy to make a static class. The work to make this class a singleton in c# is not hard either.

So does it really matter if one uses a singleton or a static class here? It seems trivial to me, but perhaps one is more appropriate for this type of thing?

I don't think I need to use interfaces, polymorphism, extensibility, or the ability to pass this class that contains these methods around. So such benefits of Singletons are not really helpful in this case. In the end the only advantages I can see is lazy loading of the class and not having to add static to every method.

Static classes work well if you have relatively little data and don't need the OOP features. I suspect that in this case, it would work well.