You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a use case that we'd like to run LB3 tests from LB4 when the LB3 app is mounted on the LB4 app. How can we run existing LB3 tests as part of LB4 project's npm test command?
Instead of migrating all tests to LB4, there should be a way to run tests from original JavaScript files stored in the LB3 project.
There are two kinda of tests:
Acceptance-level tests making HTTP calls to invoke application logic, e.g. POST /users/login This is easier because the tests need just the port number where the top-level app is listening on, this app can be the LB4 (or Express) app.
Integration-level tests that are using JS API to call application logic, e.g. MyModel.create(). These tests need a way how to access LB3 artifacts of the LB3 application booted by LB4.
It may be better to bind all LB3 models instead of the LB3 app object, so that we can inject only specific LB3 models to LB4 code
Maybe we can access LB3 models from LB4 controllers. That way we need to enhance the booter to bind the LB3 app object to LB4 application context, so that we can use regular dependency injection to access that app object from other LB4 code in the same way we are injecting only specific LB4 repositories to LB4 controllers.
Acceptance Criteria
This spike aims to:
Propose solutions for:
How to include tests from LB3 app in LB4 test suite. This may be as easy as adding lb3app/tests/**/*.js to mocha arguments. LB3 tests are not expected to pass yet, see the steps below.
How to change acceptance-level tests to use the outer LB4 app as the server to talk to, not the LB3 app. With the proposed changes in place, the acceptance-level tests (HTTP) should pass now.
Create follow-up stories to document them and make any necessary runtime improvements.
stretch goal
How to change integration-level tests to accommodate for the new LB4+LB3 and pass.
Maybe we can access LB3 models from LB4 controllers. That way we need to enhance the booter to bind the LB3 app object to LB4 application context, so that we can use regular dependency injection to access that app object from other LB4 code in the same way we are injecting only specific LB4 repositories to LB4 controllers.
How to access LB3 models (and datasources?) from LB4 code using dependency injection.
The text was updated successfully, but these errors were encountered:
Description
The spike is inspired by How to run LB3 app tests when the app is mounted in a LB4 project. And also see the comment.
There is a use case that we'd like to run LB3 tests from LB4 when the LB3 app is mounted on the LB4 app. How can we run existing LB3 tests as part of LB4 project's
npm test command
?Instead of migrating all tests to LB4, there should be a way to run tests from original JavaScript files stored in the LB3 project.
There are two kinda of tests:
Acceptance-level tests making HTTP calls to invoke application logic, e.g. POST /users/login This is easier because the tests need just the port number where the top-level app is listening on, this app can be the LB4 (or Express) app.
Integration-level tests that are using JS API to call application logic, e.g.
MyModel.create()
. These tests need a way how to access LB3 artifacts of the LB3 application booted by LB4.Some ideas from the comment:
Acceptance Criteria
This spike aims to:
Propose solutions for:
lb3app/tests/**/*.js
tomocha
arguments. LB3 tests are not expected to pass yet, see the steps below.Create follow-up stories to document them and make any necessary runtime improvements.
stretch goal
Maybe we can access LB3 models from LB4 controllers. That way we need to enhance the booter to bind the LB3 app object to LB4 application context, so that we can use regular dependency injection to access that app object from other LB4 code in the same way we are injecting only specific LB4 repositories to LB4 controllers.
The text was updated successfully, but these errors were encountered: