Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sharing resources (like a database pool) between tests #49

Open
seagreen opened this issue Aug 6, 2015 · 5 comments
Open

Sharing resources (like a database pool) between tests #49

seagreen opened this issue Aug 6, 2015 · 5 comments

Comments

@seagreen
Copy link

seagreen commented Aug 6, 2015

I have some tests that each need a database pool, but I'd rather not create an individual database pool within each test for performance reasons.

I'd like to write my tests like prop_foo :: a -> Property, and have some way to feed the result of my pool creation function mkPool :: IO a into each test.

Does HTF provide a way to do that and still use its TH test discovery? Even if one has to do discovery manually, is there a way to at least keep the same test settings and pretty results printing code as the rest of one's HTF tests?

@skogsbaer
Copy link
Owner

Good point! We are needing the feature as well. I have a plan how to implement it, but it will need some time.

@skogsbaer
Copy link
Owner

From a users point of view, it would be nice to write something similar to this:

-- define a TestResource for database connections
dbConResource :: TestResource
dbConResource = mkTestResource setup tearDown
    where
      setup = openDb "foo.db"
      tearDown = closeDb

-- write some test using this resource
test_userOk =
    withTestResource dbConResource $ \con ->
    ...

test_blub =
    withTestResource dbConResource $ \con ->
    ....

HTF then calls the setup function for the TestResource before the first test depending on the resource is run. HTF calls the tearDown function directly after the last test depending on resource has been run (prompt cleanup).

Internally, we need some restructuring in the TestManager (a test must somehow carry its resources to use) and in the ThreadPool (to allow for resource allocation and prompt deallocation).

@skogsbaer
Copy link
Owner

One more thing to consider: when implementing this feature, we should keep in mind #8 (benchmark support). For benchmarks, the setup function runs the reference benchmark (the teardown function does nothing). For this case, we also need to specify if tests should run concurrently to other tests or setup/teardown functions and if setup/teardown functions should run concurrently to other things.

@saurabhnanda
Copy link

saurabhnanda commented Jul 12, 2019

Just re-checking if this has already been implemented, or is this still being considered? I looked at HTF for the first time today, and was confused about the lack of any examples where test is being run in some sort of ReaderT Env IO monad.

After reading this issue, my takeaway is that each test is completely isolated from each other, and that each test will have to manually execute runReaderT action env within its own code. Did I understand this correctly?

@skogsbaer
Copy link
Owner

Yes, at the moment each test is run in isolation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants