Testing with Test Configuration

[Neil Chaudhuri]

When I run this code with the given test config file:

val testConfiguration = new Configuration(ConfigFactory.parseFile(new java.io.File("conf/application-test.conf")).resolve())
implicit val injector = new ScaldiApplicationBuilder().loadConfig(testConfiguration)
  .prependModule(new TestModule)
  .buildInj()

I get this error:

No binding found with following identifiers:

  * TypeTagIdentifier(play.api.inject.ApplicationLifecycle)

Can you explain why?

Thanks.

[Oleg Ilyenko]

Hi Neil,

I think the reason for this is that Play has more complex logic concerning the config. Some important properties are not included in the config when you do it manually the way you did it in the code example. I think there are several ways to solve this, but I guess the most easy one is to define a fallback to a config: 

val testConfiguration = (env: Environment) ⇒ new Configuration(

  ConfigFactory

    .parseFile(new File("conf/application-test.conf"))

    .resolve()

    .withFallback(Configuration.load(env).underlying))

implicit val injector = new ScaldiApplicationBuilder().loadConfig(testConfiguration)

  .prependModule(new TestModule)

  .buildInj()

This will fallback to a default environment-dependent config, but still you can override some properties in `conf/application-test.conf` 

Hope this helps.

Cheers,

Oleg

[Neil Chaudhuri]

Hi Oleg,

The problem when I do this is that I am kind of back where I started, which forced me to make a separate configuration file in the first place. Let me explain.

In my "real" application.conf, I have settings like this:

asset.cdn.url = ${ASSET_CDN_URL}

When I run my tests, I get this error:

Could not resolve substitution to a value: ${ASSET_CDN_URL}]

That makes sense of course. To get around this, I don't want to set up fake environment variables to my tests at execution; I'd rather set these in code. Also, ASSET_CDN_URL isn't even necessary for the tests I'm running. So basically I want to avoid all these property placeholders and just use the values specific to my "system under test."

That's why I used the test config file, but falling back to the default as you suggest exposes the same problem as before--the substitution resolving error.

Are there particular best practices I'm missing? Are my tests exposing flaws in my design? Should my "real" configuration be done differently (without the placeholders)? And if not, how do I best handle overriding these environment variables in the test itself so I can only use the configuration relevant to the test?

I know that's a lot, but I want to make sure I'm doing things the right way. 

Thanks.

[Neil Chaudhuri]

Turns out I can remove any configuration-related code altogether just by passing the test config file as an environment variable.

Thanks.