minor typo fixes + logo

config.js

@@ -1,11 +1,13 @@
+const favicon =
+  "https://rawcdn.githack.com/Shelob9/react-wordpress-testing/c85f38745d862f5f9d14792c4f52881a4568cdfd/triangle-trans.png";
 const config = {
   gatsby: {
     pathPrefix: "/react-wordpress-testing",
     siteUrl: "https://shelob9.github.io/react-wordpress-testing",
     gaTrackingId: null
   },
   header: {
-    logo: "https://placekitten.com/250/250",
+    logo: favicon,
     logoLink: "/",
     title: "JavaScript Testing In And Around WordPress",
     githubUrl: "https://github.com/shelob9/react-wordpress-testing",
@@ -43,7 +45,7 @@ const config = {
     ogImage: null,
     docsLocation:
       "https://github.com/shelob9/react-wordpress-testing/tree/master/content",
-    favicon: "https://placekitten.com/250/250"
+    favicon
   }
 };
 

content/next.md

@@ -28,7 +28,7 @@ This page also includes an example of accessibility testing. I need to expand on
 
 - In depth on e2e testing.
 - Accesibility testing for React apps.
-- Block development basics. Probably its own site/ gitbook/ etc.
+- Block development basics. Probably its own site.
 
 ## Testing React Apps For Accesibility Errors
 

content/testing-react-wordpress-blocks.md

@@ -4,7 +4,7 @@ metaTitle: "Testing WordPress Blocks"
 metaDescription: "desc"
 ---
 
-The previous section of this course/ gitbook/ etc. introduced testing for React apps. WordPress' block editor is a React app. In general, we use the same tools to test, compile and lint blocks as any other React code -- Jest, Babel, webpack, etc.
+The previous section of this site introduced testing for React apps. WordPress' block editor is a React app. In general, we use the same tools to test, compile and lint blocks as any other React code -- Jest, Babel, webpack, etc.
 
 Setting up all of that in a WordPress project, historically was a pain. The new [`@wordpress/scripts`](https://developer.wordpress.org/block-editor/packages/packages-scripts/) abstracts away the complexity of using these tools with WordPress.
 

content/testing-react-wordpress-blocks/5-writing-tdd-blocks.md

@@ -67,13 +67,13 @@ If these tests pass, we know that the componets should work together.
 
 Now that we know that our components work correctly, we need to make sure our plugin can be activated and used to add our block to the post editor. We do this by creating a WordPress site, automating the process of clicking the buttons to do that and asserting that the end result is as expected.
 
-End to end testing for WordPress blocks should get a full section of this course/ gitbook/ whatever later. It's a huge topic, I'll rush through it here.
+End to end testing for WordPress blocks should get a full section of this site later. It's a huge topic, I'll rush through it here to get you started.
 
 When we right these test, we assume that all of the components work. These tests are the most like how a user would use the plugin.
 
 ### Useing Puppetter To Automate Chrome
 
-This test tool uses headless Chrome, and is controlled using [puppetter](https://github.com/GoogleChrome/puppeteer).
+This test tool uses headless Chrome, and is controlled using [puppetter](https://github.com/GoogleChrome/puppeteer). The WordPress e2e test tools are a wrapper over Puppeteer. So, if you're not sure about how it works, check the [Puppetter docs](https://pptr.dev/).
 
 Easiest if you have WordPress running locally in Docker [like core does](https://github.com/WordPress/wordpress-develop/tree/master/tools/local-env)