On the fact that QuickNet needs it's own testrunner

[kilfour]

I am starting to get convinced it does.

I used to have a very simple implementation of this, but I never made
it public, as it wasn't good enough.

Using xunit, which, btw, I think is 'ken 'tastic, is a bit of a
workaround.

Fact is, xunit is aimed at unit testing. The code required to make the
Alchemist run an AcidTest is getting way to 'reflection-heavy' IMO.

Ideally, I really would like a GUI allowing me to select which
transitions to run, which specs to verify and even allowing for
generator adjustement. Effectively enabling one to run 'simulations'
on the system under test, and saving them as configurations,
integrating them into a buildserver, etc...

Must have : Integration with both TestDriven and Resharper.
I have no idea how to do that though. If anybody has any ideas on this
please post.

I think the current 'OO-syntax' (with the attributes and all that) is
something that we need to keep, but I really think it is time to move
away from xunit and implement our own runner as translating a property
based test to a xUnit (the pattern)- based one is : one getting to
hard, and two, loses a lot of the possiblilities. The AcidTest
Inheritance which was introduced recently allready shows some of the
problems we will face if we keep relying on xunit.

[Davy Brion]

sounds like a good idea, though it would require a lot of work :)

another thing that would be pretty important is the ability to run those tests in a CI build as well...

[Mark Meyers]

I think CI integration is actually the easy part. I've done it before. Having some kind of XmlReporter that spews out an NUnit type file is all you need to integrate with most CI build servers.

But I agree it is a must have. 

And you're right about the 'lot of work'. ;-)

Graham suggested integrating with Gallio.