Repository: phoenixframework/phoenix
Pull request #3943 (2020-07-27 07:27:22)

fix some small typos in the 'Testing' guides
* small typos
* use backticks for paths as in the rest of the docs instead of quotes


Patch:
diff --git a/lib/phoenix/presence.ex b/lib/phoenix/presence.ex
index 7d30fc529..6fbc4cb66 100644
--- a/lib/phoenix/presence.ex
+++ b/lib/phoenix/presence.ex
@@ -21,7 +21,7 @@ defmodule Phoenix.Presence do
   which uses `Phoenix.Presence` and provide the `:otp_app` which
   holds your configuration, as well as the `:pubsub_server`.
 
-      defmodule MyApp.Presence do
+      defmodule MyAppWeb.Presence do
         use Phoenix.Presence,
           otp_app: :my_app,
           pubsub_server: MyApp.PubSub
@@ -37,7 +37,7 @@ defmodule Phoenix.Presence do
 
       children = [
         ...
-        MyAppWeb.PubSub,
+        {Phoenix.PubSub, name: MyApp.PubSub},
         MyAppWeb.Presence,
         MyAppWeb.Endpoint
       ]


Test patch:
diff --git a/guides/testing/testing_channels.md b/guides/testing/testing_channels.md
index 5e3cbd80f..7a0a398cb 100644
--- a/guides/testing/testing_channels.md
+++ b/guides/testing/testing_channels.md
@@ -132,7 +132,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
 
diff --git a/guides/testing/testing_contexts.md b/guides/testing/testing_contexts.md
index 03495a96e..632ebdec5 100644
--- a/guides/testing/testing_contexts.md
+++ b/guides/testing/testing_contexts.md
@@ -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`.
 
@@ -139,7 +139,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
diff --git a/guides/testing/testing_controllers.md b/guides/testing/testing_controllers.md
index eedaf0d8b..2e7089ee2 100644
--- a/guides/testing/testing_controllers.md
+++ b/guides/testing/testing_controllers.md
@@ -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
@@ -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
@@ -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
@@ -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.
 
@@ -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: