Skip to content

Commit

Permalink
Add references from Thinking in LoopBack to Testing Your Application
Browse files Browse the repository at this point in the history
  • Loading branch information
bajtos committed Oct 13, 2017
1 parent a0544cd commit 345074a
Show file tree
Hide file tree
Showing 2 changed files with 18 additions and 12 deletions.
10 changes: 5 additions & 5 deletions pages/en/lb4/Testing-Your-application.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,16 +18,16 @@ Thorough automated testing:
- Speeds up development over the long run (the code writes itself!)
- And much more. See [benefits of software testing](http://lmgtfy.com/?q=benefits+of+software+testing)

### Types of tests

We encourage writing tests from a few perspectives, mainly [black-box testing](https://en.wikipedia.org/wiki/Black-box_testing) (acceptance) and [white-box testing](https://en.wikipedia.org/wiki/White-box_testing) (integration and unit). Tests are usually written using typical patterns such as [`act/arrange/assert`](https://msdn.microsoft.com/en-us/library/hh694602.aspx#Anchor_3) or [`given/when/then`](https://martinfowler.com/bliki/GivenWhenThen.html). While both styles work well, just pick one that you're comfortable with and start writing tests!

Please refer to [Thinking in LoopBack](./Thinking-in-LoopBack.html) for an introductory text that explains high-level concepts of automated testing in [Define your testing strategy](./Thinking-in-LoopBack.html#define-your-testing-strategy) and provides a step-by-step tutorial in [Incrementally implement features](Thinking-in-LoopBack.html#incrementally-implement-features).

{% include important.html content="A great test suite requires you to think smaller and favor fast, focused unit-tests over slow application-wide end-to-end tests
" %}

## Types of tests

We encourage writing tests from a few perspectives, mainly [black-box testing](https://en.wikipedia.org/wiki/Black-box_testing) (acceptance) and [white-box testing](https://en.wikipedia.org/wiki/White-box_testing) (integration and unit). Tests are usually written using typical patterns such as [`act/arrange/assert`](https://msdn.microsoft.com/en-us/library/hh694602.aspx#Anchor_3) or [`given/when/then`](https://martinfowler.com/bliki/GivenWhenThen.html). While both styles work well, just pick one that you're comfortable with and start writing tests!

The rest of this page contains a reference manual explaining how to write different types of tests.
The rest of this page contains a reference manual explaining how to write common types of tests and test helpers.

## Project setup

Expand Down
20 changes: 13 additions & 7 deletions pages/en/lb4/Thinking-in-LoopBack.md
Original file line number Diff line number Diff line change
Expand Up @@ -354,7 +354,7 @@ describe('API specification', () => {
});
```

See [Validate your OpenAPI specification](./Testing-your-application.html#validate-your-openapi-specification) from Testing your application for more details.
See [Validate your OpenAPI specification](./Testing-your-application.html#validate-your-openapi-specification) from [Testing your application](./Testing-your-application.html) for more details.

## Smoke test your API input/output

Expand Down Expand Up @@ -526,7 +526,7 @@ It's a powerful proposition to use the API spec not only for API declaration but

At this point, we are ready to make these tests pass by coding up your business logic.

Please refer to [Perform an auto-generated smoke test of your REST API](./Testing-your-application.html#perform-an-auto-generated-smoke-test-of-your-rest-api) from Testing your application for more details.
Please refer to [Perform an auto-generated smoke test of your REST API](./Testing-your-application.html#perform-an-auto-generated-smoke-test-of-your-rest-api) from [Testing your application](./Testing-your-application.html) for more details.

## Define your testing strategy

Expand Down Expand Up @@ -687,11 +687,11 @@ When you scroll up in the test output, you will see more information about the 4
Unhandled error in GET /product/ink-pen: 404 Error: Controller method not found: ProductController.getDetails
```

Learn more about acceptance testing in [Test your individual REST API endpoints](./Testing-your-application.html#test-your-individual-rest-api-endpoints) from Testing your application.
Learn more about acceptance testing in [Test your individual REST API endpoints](./Testing-your-application.html#test-your-individual-rest-api-endpoints) from [Testing your application](./Testing-your-application.html).

### Write a unit-test for the new controller method

Our new acceptance test is failing because there is no `getDetails` method implemented by `ProductController`. Let's start with a unit-test to drive the implementation of this new method.
Our new acceptance test is failing because there is no `getDetails` method implemented by `ProductController`. Let's start with a unit-test to drive the implementation of this new method. Please refer to [Unit-test your Controllers](./Testing-your-application.html#unit-test-your-controllers) for more details.

Create `tests/unit/product-controller.test.ts` with the following contents:

Expand Down Expand Up @@ -799,7 +799,9 @@ AssertionError: expected Object { name: 'Ink Pen', slug: 'ink-pen' } to equal Ob
}
```

Let's take a closer look at our new test. In order to make it fail with the current implementation, we need to find a different scenario compared to what is covered by our unit test. We could simply change the data, but that would add only little value to our test suite. Instead, we took this opportunity to cover another requirement of "get product details" operation - it should return the details of the product that matches the "slug" parameter passed in the arguments.
Please refer to [Test your Controllers and Repositories together](./Testing-your-application.html#test-your-controllers-and-repositories-together) to learn more about integration testing.

Let's take a closer look at our new test now. In order to make it fail with the current implementation, we need to find a different scenario compared to what is covered by our unit test. We could simply change the data, but that would add only little value to our test suite. Instead, we took this opportunity to cover another requirement of "get product details" operation - it should return the details of the product that matches the "slug" parameter passed in the arguments.

The next step is bigger than is usual in an incremental TDD workflow. We need to connect to our database and define classes to work with the data.

Expand Down Expand Up @@ -894,6 +896,8 @@ Notice that `givenProduct` is filling in required properties with sensible defau

2. It makes tests easier to maintain. As our data model evolves, we will eventually need to add more required properties. If the tests were building product instances manually, we would have to fix all tests to set the new required property. With a shared helper, there is only a single place where to add a value for the new required property.

You can learn more about test data builders in [Use test data builders](./Testing-your-application.html#use-test-data-builders) section of [Testing your application](./Testing-your-application.html).

Now that our tests are setting up the test data correctly, it's time to rework `ProductController` to make the tests pass again.

```ts
Expand All @@ -910,6 +914,7 @@ export class ProductController {
}
}
```

### Run tests

Run the tests again. These results may surprise you:
Expand Down Expand Up @@ -990,7 +995,8 @@ The new unit test is passing now, but our integration and acceptance tests are b
2. Fix the acceptance test by annotating `ProductController`'s `repository` argument with `@inject('repositories.Product')`
and binding the `ProductRepository` in the main application file where we are also binding controllers.
Learn more about Controller unit testing in [Unit-test your Controllers](./Testing-your-application.html#unit-test-your-controllers) from Testing your application.
Learn more about this topic in [Unit-test your Controllers](./Testing-your-application.html#unit-test-your-controllers)
and [Use test doubles](./Testing-your-application.html#use-test-doubles) from [Testing your application](./Testing-your-application.html).
### Handle 'product not found' error
Expand Down Expand Up @@ -1046,7 +1052,7 @@ In LoopBack 4, we decided to abandon Express/Koa-like middleware and design a di
In this guide, we are going to modify request handling in our application to print a line in the [Common Log Format](https://en.wikipedia.org/wiki/Common_Log_Format) for each request handled.
Start by writing an acceptance test. Create a new test file (e.g. `sequence.acceptance.ts`) and add the following test:
Start by writing an acceptance test, as described in [Test sequence customizations](./Testing-your-application.html#test-sequence-customizations) from [Testing your application](./Testing-your-application.html). Create a new test file (e.g. `sequence.acceptance.ts`) and add the following test:
```ts
describe('Sequence (acceptance)', () => {
Expand Down

0 comments on commit 345074a

Please sign in to comment.