obmarg / ex_unit_fixtures

A library for defining modular dependencies (fixtures) for ExUnit tests.
MIT License
13 stars 5 forks source link

Think about support for fixtures in external libraries/libraries of external fixtures. #13

Open obmarg opened 8 years ago

obmarg commented 8 years ago

It seems like it might be nice to provide a way of importing fixtures from libraries (e.g. ecto could provide an ecto sandbox database fixture), or possibly people providing entire libraries of fixtures.

This is probably possible with the current code, but it'd be good to have a think about (and document) the optimal way to do it.

obmarg commented 8 years ago

Would be good to think about how things would work with umbrella apps as well.

pdobacz commented 6 years ago

Hello @obmarg,

This is probably possible with the current code

how would you recommend doing this with current code? This would be very useful

obmarg commented 6 years ago

Hi @pdobacz - if you wanted to do this, you'd need to create a FixtureModule in the library that exposed the fixtures you wanted to share. Then you'd need to use that fixture module in any test that wanted to use those fixtures.

Guess you might need to load the fixture files using Code.require_file or similar, if they weren't part of the project that gets loaded automatically.

pdobacz commented 6 years ago

Thank you very much, we'll try that @obmarg. Just a small clarification

need to use that fixture module by use you mean use Module or just... "use"? :)

Yeah Code.require_file seems necessary, as just using the fixture makes ex_unit_fixtures not see it. So probably the require_file with dependency-fixtures be placed in test_helper.exs for the dependent app? or can you think of a more suitable location?

obmarg commented 6 years ago

Yeah, I meant you'll need to use YourFixtureModule inside the test modules that you want to use the fixtures in.

Yeah, the test_helper.exs is usually where I'd do that. I suppose an alternative might be to dynamically set the elixirc_paths depending on the Mix.env, like phoenix projects do. That way you could build a library that exposes it's fixtures when running unit tests, but those fixtures won't get pulled into production builds.