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

No guidance on how to access components for running application #108

Open
gmethvin opened this issue Dec 18, 2017 · 0 comments
Open

No guidance on how to access components for running application #108

gmethvin opened this issue Dec 18, 2017 · 0 comments

Comments

@gmethvin
Copy link
Member

gmethvin commented Dec 18, 2017

Currently there's no built-in way to access the components actually used by the running application for a given test, and there's not really any guidance on how to do so manually. You can use components, but that will create new instances rather than using the existing one. It doesn't make sense to use the injector of the current application because it's not populated for compile-time DI apps. See also playframework/playframework#8099.

One way to solve the problem is to use a trait like this to satisfy the components dependency:

trait WithComponents[C <: BuiltInComponents] extends WithApplicationComponents {
  private var _components: C = null

  // Override this to customize how new components are created.
  def newComponents: C

  // This method is used to access the current components inside a test.
  final def currentComponents: C =
    if (_components eq null) sys.error("Components not defined!") else _components

  // This method is called once when creating an application.
  // Use currentComponents to access the components inside a test.
  final def components: BuiltInComponents = {
    _components = newComponents
    _components
  }
}

While it's possible to do this yourself, it doesn't feel very obvious so I think it would be useful to add a helper like this to the library, or change the WithApplicationComponents to work like this.

Part of the problem is also that we're using variables at the class level to store the application, rather than doing all this in a local scope. This also means it doesn't make sense to run tests in the same class in parallel, because they share this state. So we may also want to recommend a local test scope for each test rather than having it automatically provided by the testing traits, something like WithApplication in play-specs2.

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

2 participants