= Test fixture sharing for test case methods / shared resources =
 When writing heavy functional test cases which have a time-consuming setUp()/tearDown() (often database related), you often want the setUp()/tearDown() step to be executed only once to run all the test cases to decrease the time required to run the test.

 The obvious drawback of this is that tests are not isolated from each other, which means that a test may pass because a test before it was run, or a test may fail because a previous test failed.

 This can easily be implemented by dynamically controlling the behavior of Fixture``Factory (should the last created fixture be returned, or should a new one be returned).

 * Open issue: how should the user specify that a shared fixture policy needs to be used?
 * Possible solutions: 
  * make this a 'property' of the fixture creation and have the Fixture``Factory look up those properties
  * provide specific methods on the Fixture``Factory and wrap them into macros for helper macro integration

 Notes: currently trying to approach this from a different angle. Shared test fixtures with single setUp/tearDown are complex to implement with some of the new features of the framework (such as multiple execution of a test case or execution of a few test cases of a test fixture). The rough idea is to dissociate the setUp/tearDown from the test fixture (let's call them ''resource'') and have the test framework properly handle those resources.

 After some thinking, the shared test fixture will be taken out. It's basically trying to achieve what the resource concept would do without materializing it. The idea of the resource concept is to have test cases depend on some resources. A resource is a simple C++ object with a setUp/tearDown, which can be retrieved using a key (likely a string identifier). A resource is shared among multiple objects and is initialized only once per test run.

 What's interesting about resources is that you have explicit resource dependency tracking and that, for example, in a concurrent test runner, you could prevent two tests using the same resource from running concurrently. This puts more complexity on the test driver side, but it provides much more flexiblity and make things easier to understand.
