|command line fixture|I answered that I didn't know of any but it would be easy to write one. (I put aside any thoughts of why this would be necessary. People use fitSharp for all kinds of things that I've never imagined.)
|mypath\myprogram.exe|my arguments|
When I started to think more carefully, I realized that fitSharp provides the capability to do this without writing any fixtures at all. In classic Fit, the first cell in a table is the name of a fixture class to be invoked. In fitSharp, if this cell does not contain the name of a fixture class, a DoFixture is created which lets us execute methods on a class without writing a fixture. So we can write a command line class:
using System.Diagnostics;Then our test looks like:
namespace myStuff {
public class CommandLine {
public void Run(string program, string arguments) {
var process = Process.Start(program, arguments);
process.WaitForExit();
}
}
}
|myStuff.CommandLine|This is a common pattern: we write a 'domain adapter' class to make it easier to invoke methods on our system under test from standard fixtures like DoFixture. These classes tend to be more flexible and reusable than if we write custom fixtures for each of our test scenarios.
|run|mypath\myprogram.exe||my arguments|
But we can go further than this. We can execute methods on the System.Diagnostics classes directly. The 'with' keyword tells DoFixture which object to execute methods on. So our test can be:
|with|type|System.Diagnostics.Process|Of course, it would be nice to not duplicate this throughout our tests, so we can define a procedure:
|with|start|mypath\myprogram.exe||my arguments|
|wait for exit|
|define|run|@program|with|@arguments|Then we can use this whenever we need to run a program:
|with|type|System.Diagnostics.Process|
|with|start|@program||@arguments|
|wait for exit|
|run|mypath\myprogram.exe|with|my arguments|This is a simple example of how we can start building a testing DSL that suits the kind of test scenarios we need to execute.