If I understood this properly:

• MbUnit creates an outermost transaction for each test run

• You can use nested transactions inside. You can commit or rollback them.

• MbUnit will automatically commit or rollback the outermost tran. on test completion dependently on presence of [Rollback] attribute.

So speaking about DO4:

• It really does not support nested transactions yet. Likely, this feature will appear later, but for now we even didn't schedule it. Btw, DO39 was supporting them really naturally, but this part was necessary in quite rare cases, so there is nothing like this in DO4 for now.

• On the other hand, you can use TestFixtureSetup/TestFixtureTearDown methods to create Domain and Session and Setup/TearDown methods to open and commit/rollback a transaction based on attributes of executed test.

• You won't be able to have nested transactions, but... Are they really necessary? Just do nothing instead of commit, and try to rollback the whole test pass results, since there is no way to rollback a part of operations inside the transaction yet. As far as I imagine, rolling back nested transaction must be quite rare case... Ok, I ca imagine we need something like this to test how\if rollback works, but it's difficult to imagine when regular application really needs this.

Few examples of using Setup/TearDown:

• http://code.google.com/p/ormbattle/sour ... /DOTest.cs

• [DO4]\Install\Templates\CSharp\UnitTests\AutoBuildTest.cs

You can rollback the state, but not with "memory://". Although if you will commit something, you won't be able to roll it back.

Concerning memory:// & tests in general:

• Recreate mode now must be quite fast even for very large models

• DO4 insertion speed is also quite close to the topmost possible. In fact, it must take ~ 1/10th of second to create ~ 2-3K test entities.

• Finally, we're the only ones providing uber batching ;) So everything must be pretty fast even if your CUD operations are mixed with queries \ fetches.

So in general, recreating the storage might work well.

Another option is to make all the tests leaving storage in "testable" state - i.e. a state that allow other (or further - normally they're sequenced) tests to pass properly. Normally we use this approach. If this won't work for some test fixture, ensure it resets the state on start.