Unless you have a strong customer-authored test requirement it seems easier to drive layer testing with an xUnit tool and write tests in the same language that you code in.
Provided you have something like a hexagonal architecture, one alternative is always to use a custom test harness, built in WinForms, as a front end to provide those inputs that performs the layer test. In other words we riff of the FIT testing idea, but use our own engine instead of using FIT. The cost here doesn’t tend to be material in a larger project, but I guess smaller projects could find it hard to justify the cost of a write your own layer testing tools approach. In that case just write the acceptance test cases in xUnit. They can still give you layer testing, you just lose the flexibility of variable inputs. Of course parameterized or data-driven tests can help here and xUnit implementations like MbUnit and MsTest support calling the same test with a range of parameters.
In another approach we could abandon layer testing and use something like NUnitForms, Selenium, or Watir to drive the UI to get scripted acceptance tests. The difficulty here is that UI tests tend to be fragile; every time the UI changes, your tests need to change too. This makes them expensive and every time I use one of these, I tend to end up backing off because of the cost of maintaining the test suite.
Acceptance tests are vital to knowing ‘when we are done’ but the sweet-spot for how to make them maintainable still seems to be eluding us.