@@ -103,7 +103,7 @@ database is not something we want to clean before each test it's handy to use an
103
103
independent in-memory datasource which is filled appropriately using
104
104
[ test data builders] ( #use-test-data-builders ) before each test run.
105
105
106
- {% include code-caption.html content="test /fixtures/datasources/testdb.datasource.ts" %}
106
+ {% include code-caption.html content="src/ __ tests __ /fixtures/datasources/testdb.datasource.ts" %}
107
107
108
108
``` ts
109
109
import {juggler } from ' @loopback/repository' ;
@@ -126,7 +126,7 @@ database in the state that caused the test to fail.
126
126
To clean the database before each test, set up a ` beforeEach ` hook to call a
127
127
helper method; for example:
128
128
129
- {% include code-caption.html content="test /helpers/database.helpers.ts" %}
129
+ {% include code-caption.html content="src/ __ tests __ /helpers/database.helpers.ts" %}
130
130
131
131
``` ts
132
132
import {ProductRepository , CategoryRepository } from ' ../../src/repositories' ;
@@ -141,7 +141,7 @@ export async function givenEmptyDatabase() {
141
141
In case a repository includes a relation to another repository, ie. Product
142
142
belongs to Category, include it in the repository call, for example:
143
143
144
- {% include code-caption.html content="test /helpers/database.helpers.ts" %}
144
+ {% include code-caption.html content="src/ __ tests __ /helpers/database.helpers.ts" %}
145
145
146
146
``` ts
147
147
import {Getter } from ' @loopback/context' ;
@@ -160,7 +160,7 @@ export async function givenEmptyDatabase() {
160
160
}
161
161
```
162
162
163
- {% include code-caption.html content="test /integration/controllers/product.controller.integration.ts" %}
163
+ {% include code-caption.html content="src/ __ tests __ /integration/controllers/product.controller.integration.ts" %}
164
164
165
165
``` ts
166
166
// in your test file
@@ -198,7 +198,7 @@ documents.
198
198
In practice, a simple function that adds missing required properties is
199
199
sufficient.
200
200
201
- {% include code-caption.html content="test /helpers/database.helpers.ts" %}
201
+ {% include code-caption.html content="src/ __ tests __ /helpers/database.helpers.ts" %}
202
202
203
203
``` ts
204
204
// ...
@@ -432,7 +432,7 @@ implementation of its repository dependency using the `testlab`
432
432
[ Create a stub repository] ( #create-a-stub-repository ) for a detailed
433
433
explanation.
434
434
435
- {% include code-caption.html content="test /unit/controllers/product.controller.unit.ts" %}
435
+ {% include code-caption.html content="src/ __ tests __ /unit/controllers/product.controller.unit.ts" %}
436
436
437
437
``` ts
438
438
import {
@@ -482,7 +482,7 @@ unit tests to verify the implementation of this additional method.
482
482
Remember to use [ Test data builders] ( #use-test-data-builders ) whenever you need
483
483
valid data to create a new model instance.
484
484
485
- {% include code-caption.html content="test /unit/models/person.model.unit.ts" %}
485
+ {% include code-caption.html content="src/ __ tests __ /unit/models/person.model.unit.ts" %}
486
486
487
487
``` ts
488
488
import {Person } from ' ../../../src/models' ;
@@ -569,7 +569,7 @@ Integration tests are one of the places to put the best practices in
569
569
Here is an example showing how to write an integration test for a custom
570
570
repository method ` findByName ` :
571
571
572
- {% include code-caption.html content="test /integration/repositories/category.repository.integration.ts" %}
572
+ {% include code-caption.html content="src/ __ tests __ /integration/repositories/category.repository.integration.ts" %}
573
573
574
574
``` ts
575
575
import {
@@ -604,7 +604,7 @@ commands and queries produce expected results when executed on a real database.
604
604
These tests are similar to repository tests with controllers added as another
605
605
ingredient.
606
606
607
- {% include code-caption.html content="test /integration/controllers/product.controller.integration.ts" %}
607
+ {% include code-caption.html content="src/ __ tests __ /integration/controllers/product.controller.integration.ts" %}
608
608
609
609
``` ts
610
610
import {expect } from ' @loopback/testlab' ;
@@ -742,10 +742,9 @@ provides a helper method `validateApiSpec` that builds on top of the popular
742
742
743
743
Example usage:
744
744
745
- {% include code-caption.html content= "test /acceptance/api-spec.acceptance.ts" %}
745
+ {% include code-caption.html content= "src/ __ tests __ /acceptance/api-spec.acceptance.ts" %}
746
746
747
747
``` ts
748
- // test/acceptance/api-spec.test.ts
749
748
import {HelloWorldApplication } from ' ../..' ;
750
749
import {RestServer } from ' @loopback/rest' ;
751
750
import {validateApiSpec } from ' @loopback/testlab' ;
@@ -785,7 +784,7 @@ developers consuming your API will find them useful too.
785
784
786
785
Here is an example showing how to run Dredd to test your API against the spec:
787
786
788
- {% include code-caption.html content= "test /acceptance/api-spec.acceptance.ts" %}
787
+ {% include code-caption.html content= "src/ __ tests __ /acceptance/api-spec.acceptance.ts" %}
789
788
790
789
``` ts
791
790
import {expect } from ' @loopback/testlab' ;
@@ -857,7 +856,7 @@ two tests (one test for each user role).
857
856
858
857
Here is an example of an acceptance test:
859
858
860
- {% include code-caption.html content= "test /acceptance/product.acceptance.ts" %}
859
+ {% include code-caption.html content= "src/ __ tests __ /acceptance/product.acceptance.ts" %}
861
860
862
861
``` ts
863
862
import {HelloWorldApplication } from ' ../..' ;
0 commit comments