Scaffold test files to src/__tests__ + small fixes

benchmark/package.json

@@ -18,7 +18,7 @@
     "pretest": "npm run clean && npm run build",
     "test": "lb-mocha \"dist/__tests__\"",
     "prestart": "npm run build",
-    "benchmark:routing": "node ./dist/src/rest-routing/routing-table",
+    "benchmark:routing": "node ./dist/rest-routing/routing-table",
     "start": "node ."
   },
   "repository": {
@@ -30,9 +30,9 @@
     "README.md",
     "index.js",
     "index.d.ts",
-    "dist/src",
-    "dist/index*",
-    "src"
+    "dist",
+    "src",
+    "!*/__tests__"
   ],
   "dependencies": {
     "@loopback/example-todo": "^1.4.2",

benchmark/tsconfig.build.json

@@ -2,7 +2,7 @@
   "$schema": "http://json.schemastore.org/tsconfig",
   "extends": "@loopback/build/config/tsconfig.common.json",
   "compilerOptions": {
-    "rootDir": "."
+    "rootDir": "src"
   },
-  "include": ["index.ts", "src", "test"]
+  "include": ["src"]
 }

docs/site/Application-generator.md

@@ -76,6 +76,7 @@ the following files and directories:
 ```text
 .
 ├── src/
+|   ├── __tests__/
 |   ├── controllers/
 |   |   └── ping.controller.ts
 |   ├── datasources/
@@ -84,7 +85,6 @@ the following files and directories:
 |   ├── application.ts
 |   ├── index.ts
 |   └── sequence.ts
-├── test/
 └── package.json
 ```
 

docs/site/Controllers.md

@@ -239,11 +239,11 @@ codes is found
 The example below shows the previous controller revamped with `HttpErrors` along
 with a test to verify that the error is thrown properly.
 
-{% include code-caption.html content="test/integration/controllers/hello.controller.integration.ts" %}
+{% include code-caption.html content="src/__tests__/integration/controllers/hello.controller.integration.ts" %}
 
 ```ts
-import {HelloController} from '../../../src/controllers';
-import {HelloRepository} from '../../../src/repositories';
+import {HelloController} from '../../../controllers';
+import {HelloRepository} from '../../../repositories';
 import {testdb} from '../../fixtures/datasources/testdb.datasource';
 import {expect} from '@loopback/testlab';
 import {HttpErrors} from '@loopback/rest';

docs/site/DEVELOPING.md

@@ -148,9 +148,9 @@ tests (unit, acceptance and integration), with the convention
 Examples are:
 
 ```
-test/acceptance/application.acceptance.ts
-test/integration/user.controller.integration.ts
-test/unit/application.unit.ts
+src/__tests__/acceptance/application.acceptance.ts
+src/__tests__/integration/user.controller.integration.ts
+src/__tests__/unit/application.unit.ts
 ```
 
 ## API Documentation

docs/site/Defining-the-API-using-design-first-approach.shelved.md

@@ -408,7 +408,7 @@ module provides a helper function for checking whether a specification conforms
 to OpenAPI Spec. Just add a new Mocha test that calls this helper function to
 the test suite:
 
-{% include code-caption.html content="test/acceptance/api-spec.acceptance.ts" %}
+{% include code-caption.html content="src/__tests__/acceptance/api-spec.acceptance.ts" %}
 
 ```ts
 import {validateApiSpec} from '@loopback/testlab';

docs/site/Implementing-features.shelved.md

@@ -35,7 +35,8 @@ search for a given product name, and verify that expected products were
 returned. This verifies that all parts of your application are correctly wired
 together.
 
-Create `test/acceptance/product.acceptance.ts` with the following contents:
+Create `src/__tests__/acceptance/product.acceptance.ts` with the following
+contents:
 
 ```ts
 import {HelloWorldApp} from '../..';
@@ -163,7 +164,7 @@ Run `npm test` and watch the test fail with a helpful error message:
 
 ```text
 TSError: ⨯ Unable to compile TypeScript
-test/unit/product-controller.test.ts (13,40): Property 'getDetails' does not exist on type 'ProductController'. (2339)
+src/__tests__/unit/product-controller.test.ts (13,40): Property 'getDetails' does not exist on type 'ProductController'. (2339)
 ```
 
 Now it's time to write the first implementation of the `getDetails` method.
@@ -412,8 +413,8 @@ Examine the acceptance test first. A quick review of the source code should tell
 us what's the problem - the test is relying on `givenEmptyDatabase` and
 `givenProduct` helpers, but these helpers are not fully implemented yet. Fix
 that by reusing the helpers from the integration test: Move the helpers to
-`test/helpers/database.helpers.ts` and update both the acceptance and the
-integration tests to import the helpers from there.
+`src/__tests__/helpers/database.helpers.ts` and update both the acceptance and
+the integration tests to import the helpers from there.
 
 To find out why the API smoke test is failing, you can start the application via
 `node .` and request the tested endpoint for example using `curl`. You will see

docs/site/Testing-Your-Extensions.md

@@ -84,7 +84,7 @@ export class PingController {
 }
 ```
 
-{% include code-caption.html content="test/unit/controllers/ping.controller.unit.ts" %}
+{% include code-caption.html content="src/__tests__/unit/controllers/ping.controller.unit.ts" %}
 
 ```ts
 import {PingController} from '../../..';
@@ -145,7 +145,7 @@ export function getTestMetadata(
 }
 ```
 
-{% include code-caption.html content="test/unit/decorators/test.decorator.unit.ts" %}
+{% include code-caption.html content="src/__tests__/unit/decorators/test.decorator.unit.ts" %}
 
 ```ts
 import {test, getTestMetadata} from '../../..';
@@ -194,7 +194,7 @@ export class RandomNumberProvider implements Provider<number> {
 }
 ```
 
-{% include code-caption.html content="test/unit/providers/random-number.provider.unit.ts" %}
+{% include code-caption.html content="src/__tests__/unit/providers/random-number.provider.unit.ts" %}
 
 ```ts
 import {RandomNumberProvider} from '../../..';
@@ -255,7 +255,7 @@ export function TimeMixin<T extends Constructor<any>>(superClass: T) {
 }
 ```
 
-{% include code-caption.html content="test/integration/mixins/time.mixin.integration.ts" %}
+{% include code-caption.html content="src/__tests__/integration/mixins/time.mixin.integration.ts" %}
 
 ```ts
 import {expect} from '@loopback/testlab';
@@ -302,4 +302,4 @@ Have a look at
 [loopback4-example-log-extension](https://github.com/strongloop/loopback-next/tree/master/examples/log-extension)
 to understand the extension artifacts and their usage. An Acceptance test can be
 seen here:
-[test/acceptance/log.extension.acceptance.ts](https://github.com/strongloop/loopback-next/blob/master/examples/log-extension/test/acceptance/log.extension.acceptance.ts).
+[src/**tests**/acceptance/log.extension.acceptance.ts](https://github.com/strongloop/loopback-next/blob/master/examples/log-extension/src/__tests__/acceptance/log.extension.acceptance.ts).

docs/site/Testing-your-application.md

@@ -103,7 +103,7 @@ database is not something we want to clean before each test it's handy to use an
 independent in-memory datasource which is filled appropriately using
 [test data builders](#use-test-data-builders) before each test run.
 
-{% include code-caption.html content="test/fixtures/datasources/testdb.datasource.ts" %}
+{% include code-caption.html content="src/__tests__/fixtures/datasources/testdb.datasource.ts" %}
 
 ```ts
 import {juggler} from '@loopback/repository';
@@ -126,7 +126,7 @@ database in the state that caused the test to fail.
 To clean the database before each test, set up a `beforeEach` hook to call a
 helper method; for example:
 
-{% include code-caption.html content="test/helpers/database.helpers.ts" %}
+{% include code-caption.html content="src/__tests__/helpers/database.helpers.ts" %}
 
 ```ts
 import {ProductRepository, CategoryRepository} from '../../src/repositories';
@@ -141,7 +141,7 @@ export async function givenEmptyDatabase() {
 In case a repository includes a relation to another repository, ie. Product
 belongs to Category, include it in the repository call, for example:
 
-{% include code-caption.html content="test/helpers/database.helpers.ts" %}
+{% include code-caption.html content="src/__tests__/helpers/database.helpers.ts" %}
 
 ```ts
 import {Getter} from '@loopback/context';
@@ -160,7 +160,7 @@ export async function givenEmptyDatabase() {
 }
 ```
 
-{% include code-caption.html content="test/integration/controllers/product.controller.integration.ts" %}
+{% include code-caption.html content="src/__tests__/integration/controllers/product.controller.integration.ts" %}
 
 ```ts
 // in your test file
@@ -198,7 +198,7 @@ documents.
 In practice, a simple function that adds missing required properties is
 sufficient.
 
-{% include code-caption.html content="test/helpers/database.helpers.ts" %}
+{% include code-caption.html content="src/__tests__/helpers/database.helpers.ts" %}
 
 ```ts
 // ...
@@ -432,7 +432,7 @@ implementation of its repository dependency using the `testlab`
 [Create a stub repository](#create-a-stub-repository) for a detailed
 explanation.
 
-{% include code-caption.html content="test/unit/controllers/product.controller.unit.ts" %}
+{% include code-caption.html content="src/__tests__/unit/controllers/product.controller.unit.ts" %}
 
 ```ts
 import {
@@ -482,7 +482,7 @@ unit tests to verify the implementation of this additional method.
 Remember to use [Test data builders](#use-test-data-builders) whenever you need
 valid data to create a new model instance.
 
-{% include code-caption.html content="test/unit/models/person.model.unit.ts" %}
+{% include code-caption.html content="src/__tests__/unit/models/person.model.unit.ts" %}
 
 ```ts
 import {Person} from '../../../src/models';
@@ -569,7 +569,7 @@ Integration tests are one of the places to put the best practices in
 Here is an example showing how to write an integration test for a custom
 repository method `findByName`:
 
-{% include code-caption.html content="test/integration/repositories/category.repository.integration.ts" %}
+{% include code-caption.html content="src/__tests__/integration/repositories/category.repository.integration.ts" %}
 
 ```ts
 import {
@@ -604,7 +604,7 @@ commands and queries produce expected results when executed on a real database.
 These tests are similar to repository tests with controllers added as another
 ingredient.
 
-{% include code-caption.html content="test/integration/controllers/product.controller.integration.ts" %}
+{% include code-caption.html content="src/__tests__/integration/controllers/product.controller.integration.ts" %}
 
 ```ts
 import {expect} from '@loopback/testlab';
@@ -742,10 +742,9 @@ provides a helper method `validateApiSpec` that builds on top of the popular
 
 Example usage:
 
-{% include code-caption.html content= "test/acceptance/api-spec.acceptance.ts" %}
+{% include code-caption.html content= "src/__tests__/acceptance/api-spec.acceptance.ts" %}
 
 ```ts
-// test/acceptance/api-spec.test.ts
 import {HelloWorldApplication} from '../..';
 import {RestServer} from '@loopback/rest';
 import {validateApiSpec} from '@loopback/testlab';
@@ -785,7 +784,7 @@ developers consuming your API will find them useful too.
 
 Here is an example showing how to run Dredd to test your API against the spec:
 
-{% include code-caption.html content= "test/acceptance/api-spec.acceptance.ts" %}
+{% include code-caption.html content= "src/__tests__/acceptance/api-spec.acceptance.ts" %}
 
 ```ts
 import {expect} from '@loopback/testlab';
@@ -857,7 +856,7 @@ two tests (one test for each user role).
 
 Here is an example of an acceptance test:
 
-{% include code-caption.html content= "test/acceptance/product.acceptance.ts" %}
+{% include code-caption.html content= "src/__tests__/acceptance/product.acceptance.ts" %}
 
 ```ts
 import {HelloWorldApplication} from '../..';