- Keep Calm! Test On!
- Now that you're familiar with the concepts of testing, your goal is to write documentation and tests for an API that is already in production. (This happens a lot :))
- Answers to your written questions will be recorded in ANSWERS.md
- This is to be worked on alone but you can use outside resources. You can reference any old code you may have, and the React Documentation, however, please refrain from copying and pasting any of your answers. Try and understand the question and put your responses in your own words. Be as thorough as possible when explaining something.
- Just a friendly Reminder Don't fret or get anxious about this, this is a no-pressure assessment that is only going to help guide you here in the near future. This is NOT a pass/fail situation.
Questions - Self Study - You can exercise your Google-Fu for this and any other Sprint Challenge in the future.
- In Mocha, what are the differences between
before
,after
,beforeEach
, andafterEach
? When do they run? What are they used for? - What is the point of Test Driven Development? What do you personally think about this approach?
- What is a
spy
insinon
? How do we use it to effectively test acallback
?
- Fork/Clone this project into a directory on your machine.
cd
into your forked local copy.- notice there is a
package.json
file included. We have included all of the dev-dependencies that you'll need to build your project. - run
yarn
to download and install all the dependencies you need for this project. - run
yarn test
to start your tests. - Keep an active log of your changes by committing with Git and pushing often to GitHub.
- Write all of your tests in the
server.test.js
file. This is where you're going to be doing your API mocking/testing.
- You're going to be writing the documentation and the tests for a CRUD API.
- The API itself is really simple. Your task is to peek at the endpoints found in the
server.js
file and write docs for each one, then write the tests for the end points.
This API is for interfacting with classic NES/Famicom games. This is an open source project. For contributing please reference this contribution guide.
- The following is a list of all of the endpoints that you have available for use with our API. Fields with an asterisk are required in the body of the request.
TYPE | URL | DATA |
---|---|---|
POST | /api/game/create | title*, genre*, releaseDate |
GET | /api/game/get | title, genre, releaseDate, id |
PUT | /api/game/update/:id | id*, title, genre, releaseDate |
DELETE | /api/game/destroy/:id | number deleted |
- The provided API has already been manually tested for you.
- Your job is to write unit tests to ensure that the end points do what they're supposed to do.
- Each endpoint should have multiple tests to ensure that different sorts of input are handled correctly/as expected. As a guideline, write at least two tests for each endpoint.
- THERE IS NO NEED TO
YARN START
, BUT YOU'LL WANT TO ENSURE THAT YOU HAVE AMONGO
INSTANCE UP AND RUNNING.
-
The
POST
method should take in an object that looks like this{ title: 'California Games', genre: 'Sports', releaseDate: 'June 1987' }
-
Our get method should return the list of games.
-
REMINDER That this data structure returned from Mongo will be an array, so to test your game with a
beforeEach
hook you'll need to make sure you test against the first item in the arrayexpect(res.data[0].foo).to.equal(bar.foo);
-
Write your
PUT
and yourDELETE
DELETE
can take an ID off of the route parameter, or off of the req.body. It's your choice.
- Just like in class, send up the information you want changed on the server via the
req.body
. - You can send up the Id and the Server will be using that to find the record and then when found, update the record with the
req.body
info you sent up