Is there an idiomatic approach to breaking up dependencies and tests based on the idea of “unit”, “integration” and “e2e”?
- our application has multiple “slow to boot” dependencies
- our test suite requires all dependencies to boot before a test run
- it would be nice to simple use mox for a “unit” test suite and not require all the “slow to boot” dependencies
- if we wish to test against the actual dependencies, remove “mox” and boot the appropriate applications
Do you mean wanting something like the built-in tags system? Or something else?
So the built in tags system doesn’t quite do what I wish to do.
I have an umbrella named “big-code-base” and it has 20 apps in it. Inside app “A”, I run the command “mix test”. This is going to run all of the tests in the test directory.
Now, some of these tests rely on an external dep called “super-slow-to-boot-dep” and some of the tests have used mox to mock out the calls to “super-slow-to-boot-dep”. If I use the tag system and specify “mock” tags, the app “A” will still try to boot up “super-slow-to-boot-dep” because it is a dependency of app “A”. This causes problems mainly because “super-slow-to-boot-dep” is really slow and most of the time I don’t wish to run tests that use it very often (hence mocking them out).
Is there a way to only boot specific deps based on which tests are run? Or possibly, can we build the test suite to be something like “mix unit” and “mix full” where the “mix unit” will not boot up all of the dependencies?
mix.exs you can use multiple
deps/1 functions and call them with
deps(Mix.env()), similar to how phoenix handles
elixirc_paths/1. Then you just need to start the slow dependency within
test_helpers.exs by calling
Application.ensure_all_started if you want to test with it. You can use the tag system to let the application only start if a specific test tag is enabled.