You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A test case using a fixture and containing nested test cases results in a different instance of the fixture for each nested test case. But sometimes a fixture should be shared between all the tests, such as a fixture for an expensive resource that's safe to access concurrently by independent clients (such as a pool of connections to a service used by tests).
Test cases could possibly provide a #:singleton or #:shared keyword that can be used after a fixture clause to trigger this behavior. But some fixtures almost always want to be shared, and callers would have to use the keyword every time they used the fixture.
Alternatively, fixtures could be defined with some sort of "scope" value attached that defines when new values are allocated and when they're reused. Some sort of "test module scope" could mean that all test cases in the same module reuse the fixture value, and some sort of "place scope" could mean that all test cases in the same place should reuse the fixture value. That would require some sort of integration with test runners. Much thinking to do here.
The text was updated successfully, but these errors were encountered:
A test case using a fixture and containing nested test cases results in a different instance of the fixture for each nested test case. But sometimes a fixture should be shared between all the tests, such as a fixture for an expensive resource that's safe to access concurrently by independent clients (such as a pool of connections to a service used by tests).
Test cases could possibly provide a
#:singleton
or#:shared
keyword that can be used after a fixture clause to trigger this behavior. But some fixtures almost always want to be shared, and callers would have to use the keyword every time they used the fixture.Alternatively, fixtures could be defined with some sort of "scope" value attached that defines when new values are allocated and when they're reused. Some sort of "test module scope" could mean that all test cases in the same module reuse the fixture value, and some sort of "place scope" could mean that all test cases in the same place should reuse the fixture value. That would require some sort of integration with test runners. Much thinking to do here.
The text was updated successfully, but these errors were encountered: