Your feedback on the System.Diagnostics.Abstractions API is requested...

readme.md

I'm working on a small project, inspired by the awesome System.IO.Abstractions, aiming to provide a wrapper over System.Diagnostics.Process, to assist testability of anything process-related.

Where System.IO.Abstractions provides a wrapper over the Path, File, Directory types, as well as a wrapper objects over FileInfo and DirectoryInfo, all conveniently accessible from an IFileSystem, mirroring the way those types exist today in the .NET framework, the System.Diagnostics.Process type presents its own challenges when trying to create a convenient wrapper.

Your feedback on the API is, therefore, very much appreciated.

The Process class has several static methods for launching a new process, as well as other stuff:

void EnterDebugMode();
Process GetCurrentProcess();
Process GetProcessById(int processId);
Process GetProcessById(int processId, string machineName);
Process[] GetProcesses();
Process[] GetProcesses(string machineName);
Process[] GetProcessesByName(string processName);
Process[] GetProcessesByName(string processName, string machineName);
void LeaveDebugMode();

Process Start(ProcessStartInfo startInfo);
Process Start(string fileName);
Process Start(string fileName, string arguments);
Process Start(string fileName, string userName, SecureString password, string domain);
Process Start(string fileName, string arguments, string userName, SecureString password, string domain);

In addition, the instance methods of Process also have lots in them.

My initial idea for the API is to create the following:

1. An injectable IProcessSystem interface, containing the "static" method signatures (see above). From this interface it would be possible to start a process instance, just as it's possible via the static method:

   Process process = Process.Start("calc.exe");

   becomes

   IProcessSystem processSystem = ... // get process system wrapper somehow IProcess process = processSystem.Start("calc.exe");

2. In addition, the ability to create processes directly by using a ProcessWrapper class, having the same methods as the original Process class:

var process = new Process();
process.StartInfo.FileName = "calc.exe";
process.Start();

becomes

`var process = new ProcessWrapper();`  
`process.StartInfo.FileName = "calc.exe";`    
`process.Start();`

ProcessWrapper implements IProcess and derives from ProcessBase, which contains abstract definitions of the methods of the System.Diagnostics.Process type.

Few questions:

1. What do you think about the name IProcessSystem to hold the static methods of Process? Can it be named something else?

2. Thinking about testability, should this library discourage from creating ProcessWrapper instances directly, and using only the IProcessSystem methods?

3. Should I add new API to IProcessSystem, allowing, for example, create processes without starting them (currently not possible using the static Process.Start methods)?

1. IProcessSystem sounds fine to me. Maybe consider something like IProcessManager as well, though. If you have one interface that's just for creating processes then I'd suggest IProcessFactory.
2. If you're aiming for testability, you definitely want to discourage direct instantiation of the concrete classes. What does creating a ProcessWrapper instance directly do that just creating a Process doesn't?
3. Yes, common patterns would definitely be a great thing to include. Remove all the boilerplate. :)

I agree with Daniel.

IProcessFactory - to create all the things
IProcessManager - to manage all the things

Ignore the fact that statics exist on Process, this is a new API (even though you will consume the statics under the hood)

The one problem with System.IO.Abstractions is that it tries too hard to mirror the existing full framework API, which means it is still not easily portable to other framework runtimes. Identify all the frameworks you want to support and make that known now.