Skip to content

Commit

Permalink
Fix some small typos in the 'Testing' guides (#3943)
Browse files Browse the repository at this point in the history
  • Loading branch information
sfusato authored and chrismccord committed Sep 21, 2020
1 parent 2fa7d16 commit 4ee3484
Show file tree
Hide file tree
Showing 3 changed files with 8 additions and 8 deletions.
2 changes: 1 addition & 1 deletion guides/testing/testing_channels.md
Original file line number Diff line number Diff line change
Expand Up @@ -136,7 +136,7 @@ We notice that we access the same `socket` that is from the setup block. How han

Since the `handle_in/3` callback for the `"shout"` event just broadcasts the same event and payload, all subscribers in the `"room:lobby"` should receive the message. To check that, we do `assert_broadcast "shout", %{"hello" => "all"}`.

**NOTE:** `assert_broadcast/3` tests that the message was broadcast in the PubSub system. For testing if a client receives a message, use `assert_push/3`
**NOTE:** `assert_broadcast/3` tests that the message was broadcast in the PubSub system. For testing if a client receives a message, use `assert_push/3`.

### Testing an asynchronous push from the server

Expand Down
4 changes: 2 additions & 2 deletions guides/testing/testing_contexts.md
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,7 @@ defmodule Hello.BlogTest do
...
```

As the top of the file we import `Hello.DataCase`, which as we will see soon, it is similar to `HelloWeb.ConnCase`. While `HelloWeb.ConnCase` set up helpers for working with connections, which is useful when testing controllers and views, `Hello.DataCase` provides functionality for working with contexts and schemas.
As the top of the file we import `Hello.DataCase`, which as we will see soon, it is similar to `HelloWeb.ConnCase`. While `HelloWeb.ConnCase` sets up helpers for working with connections, which is useful when testing controllers and views, `Hello.DataCase` provides functionality for working with contexts and schemas.

Next we define an alias, so we can refer to `Hello.Blog` simply as `Blog`.

Expand Down Expand Up @@ -143,7 +143,7 @@ You may be wondering then: when do we test the context directly and when do we t

The general guideline is to keep all side-effect free code in the schema. In other words, if you are simply working with data structures, schemas and changesets, put it in the schema. The context will typically have the code that creates and updates schemas and then write them to a database or an API.

We'll be adding additional validations to the schema module, so that's a great opportunity to write some schema specific tests. Open up `lib/hello/blog/post.ex` and add the following validadtion to `def changeset`:
We'll be adding additional validations to the schema module, so that's a great opportunity to write some schema specific tests. Open up `lib/hello/blog/post.ex` and add the following validation to `def changeset`:

```elixir
def changeset(post, attrs) do
Expand Down
10 changes: 5 additions & 5 deletions guides/testing/testing_controllers.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ This gave us a number of modules for free, including a PostController and the as

## HTML controller tests

If you open up "test/hello_web/controllers/post_controller_test.exs", you will find the following:
If you open up `test/hello_web/controllers/post_controller_test.exs`, you will find the following:

```elixir
defmodule HelloWeb.PostControllerTest do
Expand Down Expand Up @@ -246,7 +246,7 @@ With the differences in hand, let's take a look at the controller tests.

### The index action

Open up "test/hello_web/controllers/article_controller_test.exs". The initial structure is quite similar to "post_controller_test.exs". So let's take a look at the tests for the `index` action. The `index` action itself is implemented in "lib/hello_web/controllers/article_controller.ex" like this:
Open up `test/hello_web/controllers/article_controller_test.exs`. The initial structure is quite similar to `post_controller_test.exs`. So let's take a look at the tests for the `index` action. The `index` action itself is implemented in `lib/hello_web/controllers/article_controller.ex` like this:

```elixir
def index(conn, _params) do
Expand All @@ -255,7 +255,7 @@ def index(conn, _params) do
end
```

The action gets all articles and renders "index.json". Since we are talking about JSON, we don't have a "index.json.eex" template. Instead, the code that converts "articles" into JSON can be found directly in the ArticleView module, defined at "lib/hello_web/views/article_view.ex" like this:
The action gets all articles and renders "index.json". Since we are talking about JSON, we don't have a "index.json.eex" template. Instead, the code that converts "articles" into JSON can be found directly in the ArticleView module, defined at `lib/hello_web/views/article_view.ex` like this:

```elixir
defmodule HelloWeb.ArticleView do
Expand Down Expand Up @@ -291,7 +291,7 @@ describe "index" do
end
```

It simples access the `index` path, asserts we got a JSON response with status 200 and that it contains a "data" key with an empty list, as we have no articles to return.
It simply accesses the `index` path, asserts we got a JSON response with status 200 and that it contains a "data" key with an empty list, as we have no articles to return.

That was quite boring. Let's look at something more interesting.

Expand Down Expand Up @@ -339,7 +339,7 @@ def create(conn, %{"article" => article_params}) do
with {:ok, %Article{} = article} <- News.create_article(article_params) do
```

The `with` special form that ships as part of Elixir allows us to check explicitly for the happy paths. In this case, we are interested only in the scenarios where `News.create_article(article_params)` return `{:ok, article}`, if it returns anything else, the other value will simply be returned directly and none of the contents inside the `do/end` block will be executed. In other words, if `News.create_article/1` returns `{:error, changeset}`, we will simply return `{:error, changeset}` from the action.
The `with` special form that ships as part of Elixir allows us to check explicitly for the happy paths. In this case, we are interested only in the scenarios where `News.create_article(article_params)` returns `{:ok, article}`, if it returns anything else, the other value will simply be returned directly and none of the contents inside the `do/end` block will be executed. In other words, if `News.create_article/1` returns `{:error, changeset}`, we will simply return `{:error, changeset}` from the action.

However, this introduces an issue. Our actions do not know how to handle the `{:error, changeset}` result by default. Luckily, we can teach Phoenix Controllers to handle it with the Action Fallback controller. At the top of the `ArticleController`, you will find:

Expand Down

0 comments on commit 4ee3484

Please # to comment.