Integration testing Phoenix/umbrella app

Options 1 and 2 are out of questions. If you want to have full stack integration tests, you can’t take parts of the stack away…

Option 4 doesn’t work well either. You could introduce stuff there that a real user wouldn’t see, but most of the time those integration tests are about things that can happen in real user cases.

So theres only 3 left, and thats what I had done by intuition. When doing integration (or even unit tests) for a “standard” application, you are always testing your dependencies as well. Or at least you are always testing if using them does still get you the expected results even after an upgrade.

I think there might be a sweet spot there, provided I stick to the same rules in test code that I do in production code: I would use my core services to prepare initial state of the system/database, rather than touching the schemas in store app directly. I think this would still be acceptable.

an update, I’m going to try out the new lib by @josevalim for mocking so my unit tests between those layers are actually independent GitHub - dashbitco/mox: Mocks and explicit contracts in Elixir · GitHub

@hubertlepicki what type of setup did you end up with? Are you using Mox in your integration tests? Probably not since Mox is more for unit testing.

A better question is how are you setting up the mocks so that you can use the mocks for unit testing but not use them for integration testing.

We went with full stack testing from our UI app. So we prepare database, open browser, it clicks around and does hit the database.

We did get with using Mox to test core app.

When you say:

What Mix ENV do these tests run in? I ask because right now when MIX_ENV = test my code is hard-coded to always use the Mox implementation. I guess I could add something aking to the marco specified in Need naming help for macro that allows for a function to be evaluated at compile time or runtime but I’d rather keep things simple if possible (we don’t do any integration testing right now but I’d like to add some).

Right, so you most likely have an umbrella app. Umbrella apps share the configuration, so you end up with precisely the above problem.

Our app is just a folder with 3 apps now, and we require the core from ui as a dep (with path: "../core") in mix.exs, and do similar with core and db apps.

This allows us to have different configuration for test env: in core we use Mox, but in ui we don’t.

In a nutshell, we treat the other apps as if they were library dependencies. So we do have some duplication in configs, i.e. config for ui configures all 3 apps, config for core configures core and db etc.

There is a nice advantage of that: you test the db app in isolation from rest of the system, the core app is not aware at all about existence of ui. Nice bounded contexts

Yeah we are using an umbrella app which is part of why it is difficult to test the dependencies between the different apps. Maybe we should start looking at moving away from it.

I prefer to have each application as its own ‘library’ which I then include into an overall meta-application that does nothing but set up the links between the other applications. Something like having one application access another can be done by just passing the name as a config option, this also makes it really easy to test as you can essentially ‘mock’ the connection by just passing a different module into the config too.