"lb4 controller" should prepare test infrastructure

[bajtos]

This is a follow-up for #727, which added lb4 controller command that scaffolds a new CRUD controller, but does not help the user with writing the tests as we recommend in our Best Practices.

Cross-posting comment by @bajtos:

To make it easier for our users to follow the best practices and always write automated tests for their production code, lb4 controller should scaffold unit/integration/acceptance tests for the user too.

Generated tests are usually not very useful, because they are not written in test-first/test-driven style, so there is no need to generate an extensive test suite, but I think we should include at least few basic tests that will make it easier for our users to follow the best practices outlined in our docs:

• http://loopback.io/doc/en/lb4/Implementing-features.html
• http://loopback.io/doc/en/lb4/Testing-your-application.html#unit-test-your-controllers
• http://loopback.io/doc/en/lb4/Testing-your-application.html#test-controllers-and-repositories-together
• http://loopback.io/doc/en/lb4/Testing-your-application.html#test-your-individual-rest-api-endpoints

The generated code should follow the general advices:

• http://loopback.io/doc/en/lb4/Testing-your-application.html#clean-the-database-before-each-test
• http://loopback.io/doc/en/lb4/Testing-your-application.html#use-test-data-builders
• (etc.)

For example, I see a lot of value in an integration test file generated for me, one that contains database setup and test-data-builders that I can use straight away in new tests, instead of having to copy blocks of code from the docs for my test setup.

[bajtos]

@kjdelisle

I don't know if I can agree with this. As much as I like TDD and believe in the idea, I don't want to force users that don't want them to constantly be deleting them, or have to opt-out of them.
I do like the idea of potentially generating some basic unit tests for CRUD using an opt-in flag, but I definitely think it's out of the scope of the given sprint task.

I disagree. IMO, our CLI tooling should be guiding our users to do the right thing: use dependency injection to decouple different parts of their application, write a good test suite (see How to build a great test suite in our docs), etc.

If we want to make tests an opt-in feature of our CLI, then one can argue that dependency injection should be an opt-in feature too. When you don't write tests then you don't need dependency injection in your controllers and can hard-code direct reference on your models and repositories.

[bajtos]

@kjdelisle and me decided this does not really belong to MVP/Walking Skeleton.

[stale]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

[stale]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.