From 2ac58533f805d2dd8929da45ad388e761db8efd5 Mon Sep 17 00:00:00 2001 From: mai-repo Date: Thu, 2 Jan 2025 15:13:36 -0500 Subject: [PATCH 1/5] change the indentation for the motivation section --- testing-and-tdd/integration-testing.md | 34 +++++++++----------------- 1 file changed, 12 insertions(+), 22 deletions(-) diff --git a/testing-and-tdd/integration-testing.md b/testing-and-tdd/integration-testing.md index c139d331a..1603d15eb 100644 --- a/testing-and-tdd/integration-testing.md +++ b/testing-and-tdd/integration-testing.md @@ -1,6 +1,6 @@ -# Note -This lesson is too long and has significant issues. See its [#1216](https://github.com/Techtonica/curriculum/issues/1216) + + # Adding Tests to your NodeJS project @@ -25,35 +25,25 @@ Here are links to lessons that should be completed before this lesson: ### Motivation -Up to now we've been talking about _unit testing_. Unit testing is about making -sure a function behaves as expected independent of other parts of the software -system. +- Up to now we've been talking about _unit testing_. Unit testing is about making sure a function behaves as expected independent of other parts of the software system. -In most code bases functions are called not just by other functions within + In most code bases functions are called not just by other functions within the code base. They are also called by _user interfaces_ and sometimes even other programs! -When one program calls a function from within another program, that's an -_API_! APIs, or "Application Programming Interfaces" are everywhere! +- When one program calls a function from within another program, that's an +_API_! APIs, or **"Application Programming Interfaces"** are everywhere! Most APIs are distributed either as a library, that you add to your package.json and start using right away, or are exposed over the web via HTTP. -Unit testing is a powerful core skill for building maintainble software, and -the skills you're learning with jasmine or mocha or other testing frameworks -can be built upon to do _integration testing!_ - -Integration testing differes from unit testing in that it's about checking how -our code works when it's calling or being called by other programs. + Unit testing is a powerful core skill for building maintainble software, and the skills you're learning with jasmine or mocha or other testing frameworks can be built upon to do _integration testing!_ -Integration testing is _hard_, but _worth it_. As you develop your skills at -integration testing, you'll learn how to overcome the challenges posed by -writing testable code that talks to other systems. +- Integration testing differs from unit testing in that it's about checking how our code works when it's calling or being called by other programs. -As a bonus, the skills and techniques we learn, not only help make our code easier to -test but also aid readability and long term maintainability of projects. + Integration testing is _hard_, but _worth it_. As you develop your skills at integration testing, you'll learn how to overcome the challenges posed by writing testable code that talks to other systems. -This lesson discusses new tools and code patterns that help us to meet those +- **As a bonus** , the skills and techniques we learn, not only help make our code easier to test but also aid readability and long term maintainability of projects. This lesson discusses new tools and code patterns that help us to meet those challenges. ### Objectives @@ -520,7 +510,8 @@ And, of course, write unit tests for each of your new features! ## Supplemental Materials -- [MySQL and Node tutorial][mysql-node-tutorial] — A tutorial that walks through setting up a Node app that connects to MySQL database. While this isn't a PostgreSQL app, this step-by-step tutorial can provide different insight into building an app with a database. +- [Tutorial on how to build a simple app using Node JS and MySQL](https://dev.to/achowba/build-a-simple-app-using-node-js-and-mysql-19me) (Article) +- [Guide on Postgres Structure](https://node-postgres.com/guides/project-structure) (Website) [mysql-node-tutorial]: https://dev.to/achowba/build-a-simple-app-using-node-js-and-mysql-19me @@ -534,6 +525,5 @@ Optional reading that was useful while writing this lesson: - [Using PostgreSQL with Node.js][nodejs-postgres] — A simple example of using PostgreSQL within the context of a Node.js project (_not_ Express which does have some impact) - [postgres-structure]: https://node-postgres.com/guides/project-structure [express-api]: https://expressjs.com/en/4x/api.html [nodejs-postgres]: https://linuxhint.com/postgresql-nodejs-tutorial/ From 49e5b6a9c371fe6609e257c295baffe80e6092e9 Mon Sep 17 00:00:00 2001 From: mai-repo Date: Thu, 2 Jan 2025 15:24:31 -0500 Subject: [PATCH 2/5] Formatting and cleaning up links --- testing-and-tdd/integration-testing.md | 20 ++++---------------- 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/testing-and-tdd/integration-testing.md b/testing-and-tdd/integration-testing.md index 1603d15eb..0e5dbfa3b 100644 --- a/testing-and-tdd/integration-testing.md +++ b/testing-and-tdd/integration-testing.md @@ -511,19 +511,7 @@ And, of course, write unit tests for each of your new features! ## Supplemental Materials - [Tutorial on how to build a simple app using Node JS and MySQL](https://dev.to/achowba/build-a-simple-app-using-node-js-and-mysql-19me) (Article) -- [Guide on Postgres Structure](https://node-postgres.com/guides/project-structure) (Website) - -[mysql-node-tutorial]: https://dev.to/achowba/build-a-simple-app-using-node-js-and-mysql-19me - -Optional reading that was useful while writing this lesson: - -- [Testing a Database][db-testing-alt] — this discusses an alternate - approach to DB testing than we'll take at a very high level. -- [`node-postgres` structure suggestion][postgres-structure] -- [The Express API][express-api] -- [superagent api][superagent-home] — this is the API underlying `supertest` -- [Using PostgreSQL with Node.js][nodejs-postgres] — A simple example of - using PostgreSQL within the context of a Node.js project (_not_ Express which - does have some impact) - [express-api]: https://expressjs.com/en/4x/api.html - [nodejs-postgres]: https://linuxhint.com/postgresql-nodejs-tutorial/ +- [Guide to Node-Postgres](https://node-postgres.com/guides/project-structure) (Website) +- [Guide to Express](https://expressjs.com/en/4x/api.html) (Website) +- [Guide to Superagent](https://github.com/ladjs/superagent) (Website) +- [Database Testing - Software Testing](https://www.geeksforgeeks.org/software-testing-database-testing/) (Article) \ No newline at end of file From 57fe670b9830560aeb6e23a2f531d571e4bce075 Mon Sep 17 00:00:00 2001 From: mai-repo Date: Thu, 2 Jan 2025 20:27:20 -0500 Subject: [PATCH 3/5] Cleaned up links and fixed styling --- testing-and-tdd/integration-testing.md | 259 ++++++++----------------- 1 file changed, 84 insertions(+), 175 deletions(-) diff --git a/testing-and-tdd/integration-testing.md b/testing-and-tdd/integration-testing.md index 0e5dbfa3b..9468dd5e8 100644 --- a/testing-and-tdd/integration-testing.md +++ b/testing-and-tdd/integration-testing.md @@ -1,9 +1,3 @@ - - - - -# Adding Tests to your NodeJS project - [//]: # 'TODO' [//]: # ' - Still need slides' [//]: # " - This hasn't really been proofed yet and I'm _real bad_ about typos <3" @@ -15,38 +9,30 @@ [backend-ii]: https://glitch.com/edit/#!/zee-techtonica-backend-testing-ii?path=index.js:37:0 [backend-iii]: https://repl.it/@techtonica/BackendTesting-III -### Prerequisites +# Adding Tests to your NodeJS project -Here are links to lessons that should be completed before this lesson: -- [Intro to Testing and TDD][tt-testing-intro] -- [Jasmine Testing][tt-testing-frameworks] -- [Mocking and abstraction](./mocking-and-abstraction.md) +## Prerequisites -### Motivation +Here are links to lessons that should be completed before this lesson: -- Up to now we've been talking about _unit testing_. Unit testing is about making sure a function behaves as expected independent of other parts of the software system. +- [Intro to Testing and TDD](testing-and-tdd.md) +- [Jasmine Testing](jasmine-testing.md) +- [Mocking and abstraction](mocking-and-abstraction.md) - In most code bases functions are called not just by other functions within -the code base. They are also called by _user interfaces_ and sometimes even -other programs! +## Motivation -- When one program calls a function from within another program, that's an -_API_! APIs, or **"Application Programming Interfaces"** are everywhere! -Most APIs are distributed either as a library, that you add to your -package.json and start using right away, or are exposed over the web -via HTTP. +- Up to now, we've been talking about _unit testing_. Unit testing is about ensuring a function behaves as expected, independent of other parts of the software system. - Unit testing is a powerful core skill for building maintainble software, and the skills you're learning with jasmine or mocha or other testing frameworks can be built upon to do _integration testing!_ + In most codebases, functions are not just called by other functions within the codebase. They are also called by _user interfaces_ and sometimes even by other programs! -- Integration testing differs from unit testing in that it's about checking how our code works when it's calling or being called by other programs. +- When one program calls a function from within another program, that's an **API**! APIs, or **"Application Programming Interfaces"**, are everywhere! Most APIs are distributed either as a library that you add to your `package.json` and start using right away or are exposed over the web via HTTP. - Integration testing is _hard_, but _worth it_. As you develop your skills at integration testing, you'll learn how to overcome the challenges posed by writing testable code that talks to other systems. + Unit testing is a powerful core skill for building maintainable software. The skills you're learning with Jasmine, Mocha, or other testing frameworks can be built upon to do _integration testing_! -- **As a bonus** , the skills and techniques we learn, not only help make our code easier to test but also aid readability and long term maintainability of projects. This lesson discusses new tools and code patterns that help us to meet those -challenges. +- Integration testing differs from unit testing in that it’s about checking how our code works when it’s calling or being called by other programs. -### Objectives +## Objectives **Participants will be able to:** @@ -55,7 +41,7 @@ challenges. - Write code to test GET, PUT, POST and DELETE requests in your project ([Guided Practice](#Guided-Practice)) - Make a basic TODO app with unit testing to test database and other external services ([Guided Practice](#Guided-Practice)) -### Specific Things to Learn +## Specific Things to Learn **Note**: We've included links to guides on each of these when available for easy reference later. These are also included when applicable during the @@ -63,26 +49,16 @@ lesson. We do not expect you to do the tutorials linked in this "Specific Things to Learn" section today. -- General testing tools - - [Mocha][mocha-home] ([Intro To Testing][tt-testing-frameworks]) - - [Chai][chai-home] ([Intro To Testing][tt-testing-frameworks]) - - [Postman][postman-home] (guides to: [Navigating Postman][postman-nav], [Making GET requests][postman-get], [Making POST requests][postman-post]) -- Testing HTTP requests to your project - - [Supertest][supertest-home] ([intro tutorial][supertest-intro](https://www.npmjs.com/package/supertest)]) -- Testing your own database - -[tt-testing-intro]: /testing-and-tdd/testing-and-tdd.md -[tt-testing-frameworks]: jasmine-testing.md -[mocha-home]: https://mochajs.org/ -[chai-home]: https://www.chaijs.com/ -[postman-home]: https://www.getpostman.com/ -[simplemock-home]: https://www.npmjs.com/package/simple-mock -[supertest-home]: https://www.npmjs.com/package/supertest -[nock-home]: https://github.com/nock/nock -[nock-intro]: https://scotch.io/tutorials/nodejs-tests-mocking-http-requests -[postman-nav]: https://www.toolsqa.com/postman/postman-navigation/ -[postman-get]: https://www.toolsqa.com/postman/response-in-postman/ -[postman-post]: https://www.toolsqa.com/postman/post-request-in-postman/ +### General testing tools: +- [Mocha](https://mochajs.org/) (Website) +- [Chai Assertion Library](https://www.chaijs.com/) (Website) +- [Guide to Postman Navigation](https://www.toolsqa.com/postman/postman-navigation/) (Website) +- [Guide to how to a response in Postman](https://www.toolsqa.com/postman/response-in-postman/) (Article) +- [Guide to how to make a POST Request](https://www.toolsqa.com/postman/post-request-in-postman/) (Website) +- [Supertest](https://www.npmjs.com/package/supertest) (Webstie) +- [Node.js Tests: Mocking HTTP Requests](https://www.digitalocean.com/community/tutorials/nodejs-tests-mocking-http-requests) (Article) +- [Guide to Nook](https://github.com/nock/nock) (Website) +- [Guide to simple-mock](https://www.npmjs.com/package/simple-mock) (Website) ### Materials @@ -90,11 +66,9 @@ In additional to the linked material above associated with specific technologies that we'll be using there is some more general reading that will help provide depth to your understanding of API testing. -- [Backend Testing Slides][tt-backend-testing-slides] -- [7 HTTP methods every web developer should know and how to test them][testing-http-methods] +- [Backend Testing Slides](https://docs.google.com/presentation/d/1no4BY2e74QoHJlkO7LIOV-qlcqQ2viQbyJlEDyptmeY/edit?usp=sharing) (Google Slides) -[tt-backend-testing-slides]: https://docs.google.com/presentation/d/1no4BY2e74QoHJlkO7LIOV-qlcqQ2viQbyJlEDyptmeY/edit?usp=sharing -[testing-http-methods]: https://assertible.com/blog/7-http-methods-every-web-developer-should-know-and-how-to-test-them +- [7 HTTP methods every web developer should know and how to test them](https://assertible.com/blog/7-http-methods-every-web-developer-should-know-and-how-to-test-them) (Article) #### Code samples provided @@ -114,40 +88,21 @@ We will get to these code samples during Guided Practice. #### 1.1 Establishing some terminology -Before we get started let's set some ground rules about how we use terminology. -This module is called "backend testing"; but without establishing what `backend` -means, that can easily get confusing. - -Within the context of this lesson a `backend` is an API that supports some -collection of features. It often, but not always, exposes its interface through -HTTP requests and returns JSON objects as a response. +Before we get started, let's establish some ground rules for how we use terminology in this lesson. -A `backend` can be the service you're writing but it can also be something that -you depend on: +Within the context of this lesson, a **`backend`** is an API that supports a collection of features. It often—but not always—exposes its interface through HTTP requests and returns JSON objects as responses. -- a database may be a backend to your service -- your service could be the backend to your users -- the GitHub API may be a backend you depend upon +A **`backend`** can refer to the service you're writing, but it can also be something your service depends on. For example: +- A database may act as a backend to your service. +- Your service could function as the backend for your users. +- The GitHub API might be a backend your project relies on. -For this reason, it's important to provide sufficient context when talking about -using or testing a backend service. +### Key Terms -With that in mind... - -This lesson discusses backend testing in all of these frames: we will test your -service's interaction with its backend (database & external APIs) while also -writing tests to ensure your service, when used as a backend, performs as -expected. In the course of this write-up we'll use the following terms to mean -specific things: - -- "your project"— this is your code; it's written for node.js -- "API" / "API testing"— this is also your code; the node.js project - exposes its features to the world through an HTTP API, this term captures - the testing needed to ensure how you handle those requests is correct -- "backend" / "service"— this is an API that you call via HTTP; it's - called from your project -- "database"— this is a specific backend that your project uses to save - data +- **"Your project"**: This refers to the code you write for Node.js. +- **"API" / "API testing"**: This refers to your Node.js project that exposes its features to the world through an HTTP API. This term also includes the testing necessary to ensure proper handling of requests. +- **"Backend" / "Service"**: This refers to an API you call via HTTP, often from your project. +- **"Database"**: This is a specific backend your project uses to store and retrieve data. #### 1.2 Getting Started: Is API and backend/database testing special? @@ -159,10 +114,7 @@ Well, kind of; but not really... These tests are important for the same reason: We need to ensure that our code works as expected and to protect correct behavior. So framed as "is -testing important," yes it can be pretty much thought of as just more of the -same. However when you actually sit down to write these tests the interactions -with external requests (to your project) and APIs introduce interesting new -difficulties. +testing important," yes it can be pretty much thought of as just more of the same. However when you actually sit down to write these tests the interactions with external requests (to your project) and APIs introduce interesting new difficulties. #### 1.3 Facing new challenges @@ -189,41 +141,25 @@ The plan here is to first discuss some key concepts and tooling that you'll use while writing unit tests for your project and then dig into concrete examples in a small node.js + express project and corresponding tests. -How you consume this will depend your learning style. My suggestion is to skim -over [_Mocking and Abstraction_][tt-mocking] lesson then work through the examples. It's +How you consume this will depend your learning style. My suggestion is to skim over [_Mocking and Abstraction_](mocking-and-abstraction.md) lesson then work through the examples. It's pretty normal for writing code with modularity and testing in mind so don't fret if it takes more than a couple of passes for things to fall into place. -### 2. New Tool: Postman - -At its core Postman is a UI that allows us to construct simple (or complex!) -HTTP requests and inspect the results. You can think of it as a browser that -enables you to customize every aspect of the HTTP calls that are made. ToolsQA -has good collection of Postman covering basic and enterprise uses. For now -you should skim the [navigation][postman-nav], [GET request][postman-get], and -[POST request][postman-post] tutorials. +### 2. New Tool: Postman **Why use Postman?** -When building an API it's often _much_ easier to wire up a test request in -Postman than to build an HTML form (or similar) to fire off some test requests -against your API. As an example: while verifying that the TODO post code used -in this lesson worked I used Postman to quickly create POST requests to -validate behavior of the project. +- When building an API it's often _much_ easier to wire up a test request in Postman than to build an HTML form (or similar) to fire off some test requests +against your API. **Why not just use Postman?** -If Postman makes it super easy to test why shouldn't we just build all our API -tests using it? Postman primarily makes it simple to do blackbox integration -or end-to-end API testing. It's important to test this but recall that -[there are good reasons][e2e] to not rely on end-to-end testing. +- If Postman makes it super easy to test why shouldn't we just build all our API tests using it? -[e2e]: https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html +- Postman primarily makes it simple to do blackbox integration or end-to-end API testing. It's important to test this but recall that [there are good reasons](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html) +to not rely on end-to-end testing. ## Guided Practice -In this practice we're going to combine all the things we've talked about above -to build a simple TODO app that allows you to read and create TODO items and is -unit tested. We'll also cover a few approaches to testing DB calls that we don't -provide sample code. +In this practice we're going to combine all the things we've talked about above to build a simple `TODO` app that allows you to read and create `TODO` items and is unit tested. We'll also cover a few approaches to testing DB calls that we don't provide sample code. We'll be working with a database with the following schema: @@ -238,26 +174,34 @@ CREATE TABLE todo_items ( ); ``` -#### GP 0: Set up your project +### GP 0: Set up your project 0. Create a new folder for your project by following these sub-steps: 1. `mkdir todo` or whatever you want to name this new folder (and project) 2. `cd todo` + 1. Once you're in your brand-new folder, use `npm init` to initialize a new node project. 1. In your terminal, type `npm init` and press enter. This will start a new tiny command line program that helps you set up your new node project. (It will save your answers in package.json and set up some other config files for you.) + 2. The first thing it asks you is "what do you want the name to be?" (It asks for the package name because it's assuming you're making an npm package.) Notice that after the prompt, there is a _default value_ in parentheses. Whenever you see a default value in parentheses, go ahead and press "enter" to simply use the default value. + 3. Next it asks for a version, and supplies the default value (1.0.0). Go ahead and just press enter again. + 4. Continue until you get to "description" which doesn't have a default value. Write whatever short description you want, like `todo app with tests`. You can edit this later. + 5. Keep using the default value for prompts (like accept that the entry point will be `index.js`) until the tiny `npm init` program ends and you get back to your normal command line prompt. -1. Back on your normal command line prompt, install your project's dependencies: `npm install --save body-parser express pg` -1. Install your project's test dependencies: `npm install --save-dev chai mocha nock supertest` -1. Set up your database and `todo_items` table by following these steps: - 1. Create a new free database on [ElephantSQL](https://elephantsql.com/); they have - [a guide](https://www.elephantsql.com/docs/index.html) for this process. + +2. Back on your normal command line prompt, install your project's dependencies: `npm install --save body-parser express pg` + +3. Install your project's test dependencies: `npm install --save-dev chai mocha nock supertest` + +4. Set up your database and `todo_items` table by following these steps: + + 1. Create a new free database on [ElephantSQL](https://elephantsql.com/); they have [a guide](https://www.elephantsql.com/docs/index.html) for this process. 2. Use [pgAdmin](https://www.elephantsql.com/docs/pgadmin.html) or their "Browser" view to run the `CREATE TABLE` command (above) on your database -##### GP 0: Set up your project / A quick summary of accessing a DB +### GP 0: Set up your project / A quick summary of accessing a DB Your connection to most relational databases can be described in a _connection string_. It bakes into it a lot of information: @@ -273,8 +217,7 @@ dbPool.on('error', (err, client) => { }); ``` -After this we can make queries to the database by using `dbPool.query(...)`. -Its documentation is [here][pq-query] but the short version is that it takes +After this we can make queries to the database by using `dbPool.query(...)`. Its documentation is [here](https://node-postgres.com/features/queries) but the short version is that it takes three arguments: 1. the query to be run, e.g., `SELECT * from todo_items` @@ -282,55 +225,33 @@ three arguments: 3. a callback that will be made once the query is completed This should be enough to get you running but if you want to read more about -connecting to a database I suggest the [connecting][pq-connecting] and -[polling][pq-pooling] docs. - -[pq-query]: https://node-postgres.com/features/queries -[pq-connecting]: https://node-postgres.com/features/connecting -[pq-pooling]: https://node-postgres.com/features/pooling +connecting to a database I suggest the [connecting](https://node-postgres.com/features/connecting) and [pooling](https://node-postgres.com/features/pooling) docs. -#### GP 1: First steps +### GP 1: First steps (GP 1 stands for "Guided Practice Step One" here.) -You know how to build Express apps and much of the code for implementing the -necessary paths (`GET /`, `GET /items`, and `POST /`) is available above in the -_Abstraction_ section. We also just talked about how to connect to a database. +You know how to build Express apps and much of the code for implementing the necessary paths (`GET /`, `GET /items`, and `POST /`) is available above in the _Abstraction_ section. We also just talked about how to connect to a database. If you put those three things together it's enough to get a simple project -running that connects to your database and gets you started managing and viewing -TODO items. Don't worry about tests just yet, we'll make some changes that make -it easier. +running that connects to your database and gets you started managing and viewing TODO items. Don't worry about tests just yet, we'll make some changes that make it easier. -##### GP 1: First steps / Challenge +### GP 1: First steps / Challenge Once you've got the three methods up and working look at how we -refactored the read methods to make DB accesses easier to read and maintain with -`getTodo`. Rewrite the `POST /` handler to use a similar approach so that the -handler doesn't have SQL directly inside it. - -##### GP 1: First steps / Reference implementation +refactored the read methods to make DB accesses easier to read and maintain with `getTodo`. Rewrite the `POST /` handler to use a similar approach so that the handler doesn't have SQL directly inside it. -Once you have it working there is a reference -implementation on [repl.it][backend-i] if you want to see what some other -potential solutions look like. +Once you have it working there is a reference implementation on [repl.it][backend-i]. #### Interlude: Testing APIs with `supertest` -Read through [Testing Node.js with supertest][supertest-intro]. Much of this -will be familiar but it introduces a new library called `supertest`. At its -core this allows you to easily do in your unit tests what Postman was letting -you do to experiment. +Read through [Testing Node.js with supertest][supertest-intro]. Much of this will be familiar but it introduces a new library called `supertest`. At its core this allows you to easily do in your unit tests what Postman was letting you do to experiment. -#### GP 2: Refactoring for API Tests +### GP 2: Refactoring for API Tests -Now that we've got the core features solid Let's start with adding tests to our -API endpoints so that if anything breaks in the future we'll catch it. +Now that we've got the core features solid Let's start with adding tests to our API endpoints so that if anything breaks in the future we'll catch it. -The first thing we'll need to do is get the fixed reference to `getTodo` out of -the route handlers. We need to do this because it's much easier when testing to -only worry about ensuring that our code does the right thing with the data it -gets back from the Database. +The first thing we'll need to do is get the fixed reference to `getTodo` out of the route handlers. We need to do this because it's much easier when testing to only worry about ensuring that our code does the right thing with the data it gets back from the Database. ```javascript app = express() @@ -341,11 +262,7 @@ app.get('/', (req, res) => { }) ``` -What we want to accomplish is rewriting our handlers so that they don't use a -fixed implementation of `getTodo`. If we wanted to do the same thing in another -context we would wrap the behavior in a function and pass the desired -implementation in as a parameter. Further, registering a route is nothing more -than a function call on `app`. +What we want to accomplish is rewriting our handlers so that they don't use a fixed implementation of `getTodo`. If we wanted to do the same thing in another context we would wrap the behavior in a function and pass the desired implementation in as a parameter. Further, registering a route is nothing more than a function call on `app`. > Example (not part of our Todo app): > @@ -364,7 +281,7 @@ app.get('/', (req, res) => { }); ``` -> then you can drop the whole thing into a parameterized function: +Then you can drop the whole thing into a parameterized function: ```javascript const name = 'Techtonica'; @@ -390,14 +307,11 @@ registerRoute(capitalize); // or... registerRoute(lowercase); // or... registerRoute(excited); // etc ``` - > -##### Back to our TODO app now +### Back to our TODO app now -Using this same principle you can rewrite the TODO project handlers to not rely -on the global `getTodo` function as well. Give it a shot, I've included a -version below: +Using this same principle you can rewrite the TODO project handlers to not rely on the global `getTodo` function as well. Give it a shot, I've included a version below:
Code Sample (click to expand) @@ -427,11 +341,7 @@ constructRoutes(app, getTodoDB);
-Now that you have the ability to construct routes with a custom implementation of -your database calls, it's time to use **mocked-out versions of those calls** to -write simple unit tests of your request handlers. This means you can focus just -on how you process the requset and not worry about the implementation of how -we get or save TODO items. +Now that you have the ability to construct routes with a custom implementation of your database calls, it's time to use **mocked-out versions of those calls** to write simple unit tests of your request handlers. This means you can focus just on how you process the requset and not worry about the implementation of how we get or save TODO items. A simple test for `GET /` might look like: @@ -463,7 +373,7 @@ describe('GET /', () => { }); ``` -##### GP 2: Refactoring for API Tests / Challenge +### GP 2: Refactoring for API Tests / Challenge Take some time to get a feeling of how this works. Once there try to take the concepts in it and write unit tests for the case where the @@ -472,7 +382,7 @@ database calls fail. Now write the `POST /` test. What about things that aren't databases? How would you use the same principles to build testable code that utilizes external services? -##### GP 2: Refactoring for API Tests / Reference Implementation +### GP 2: Refactoring for API Tests / Reference Implementation One possible way of doing this is up on [glitch][backend-ii]. (Open the console and enter 'mocha' to run tests.) @@ -501,12 +411,11 @@ And, of course, write unit tests for each of your new features! - Pair with your partner and do a Q&A on backend testing; some example topics: - - How API / backend testing is different from unit tests you've previously - written + + - How API / backend testing is different from unit tests you've previously written - What are the benefits of not testing against live external services -- Trade code with another participant and review their solution to find how they - used the principles we discussed; are there any improvements you can find for - better readability or maintainability? + +- Trade code with another participant and review their solution to find how they used the principles we discussed; are there any improvements you can find for better readability or maintainability? ## Supplemental Materials From 2cfe2ac5fda1770ee6e73a9e0f76aad726ad133b Mon Sep 17 00:00:00 2001 From: Mai <60695595+mai-repo@users.noreply.github.com> Date: Fri, 3 Jan 2025 12:05:21 -0500 Subject: [PATCH 4/5] Paraphrase and kept in a brief description of Postman --- testing-and-tdd/integration-testing.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/testing-and-tdd/integration-testing.md b/testing-and-tdd/integration-testing.md index 9468dd5e8..9414a0454 100644 --- a/testing-and-tdd/integration-testing.md +++ b/testing-and-tdd/integration-testing.md @@ -146,7 +146,12 @@ pretty normal for writing code with modularity and testing in mind so don't fret if it takes more than a couple of passes for things to fall into place. ### 2. New Tool: Postman +Postman is a user interface that allows you to create and customize HTTP requests while inspecting their results. ToolsQA offers a helpful collection of Postman tutorials. You can start by skimming the following guides: +- [Postman's Navigation](https://www.toolsqa.com/postman/postman-navigation/) (Website) +- [Response in Postman](https://www.toolsqa.com/postman/response-in-postman/) (Website) +- [Postman Post Request](https://www.toolsqa.com/postman/post-request-in-postman/) (Website) + **Why use Postman?** - When building an API it's often _much_ easier to wire up a test request in Postman than to build an HTML form (or similar) to fire off some test requests against your API. @@ -423,4 +428,4 @@ And, of course, write unit tests for each of your new features! - [Guide to Node-Postgres](https://node-postgres.com/guides/project-structure) (Website) - [Guide to Express](https://expressjs.com/en/4x/api.html) (Website) - [Guide to Superagent](https://github.com/ladjs/superagent) (Website) -- [Database Testing - Software Testing](https://www.geeksforgeeks.org/software-testing-database-testing/) (Article) \ No newline at end of file +- [Database Testing - Software Testing](https://www.geeksforgeeks.org/software-testing-database-testing/) (Article) From 258c79300774a51a4dce02b1807e4f66dad155d2 Mon Sep 17 00:00:00 2001 From: Mai <60695595+mai-repo@users.noreply.github.com> Date: Fri, 3 Jan 2025 12:38:11 -0500 Subject: [PATCH 5/5] Fixed grammatical issue Co-authored-by: Chris Jaure --- testing-and-tdd/integration-testing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/testing-and-tdd/integration-testing.md b/testing-and-tdd/integration-testing.md index 9414a0454..35e026478 100644 --- a/testing-and-tdd/integration-testing.md +++ b/testing-and-tdd/integration-testing.md @@ -55,7 +55,7 @@ We do not expect you to do the tutorials linked in this "Specific Things to Lear - [Guide to Postman Navigation](https://www.toolsqa.com/postman/postman-navigation/) (Website) - [Guide to how to a response in Postman](https://www.toolsqa.com/postman/response-in-postman/) (Article) - [Guide to how to make a POST Request](https://www.toolsqa.com/postman/post-request-in-postman/) (Website) -- [Supertest](https://www.npmjs.com/package/supertest) (Webstie) +- [Supertest](https://www.npmjs.com/package/supertest) (Website) - [Node.js Tests: Mocking HTTP Requests](https://www.digitalocean.com/community/tutorials/nodejs-tests-mocking-http-requests) (Article) - [Guide to Nook](https://github.com/nock/nock) (Website) - [Guide to simple-mock](https://www.npmjs.com/package/simple-mock) (Website)