HoHoHo Backend Testing Module

IMPORTANT NOTES - Make sure to complete the Mocha/Chai Video Series before attempting this exercise. - Your tests should all be in the /hohoho_backend/test/api_tests.js file

Today you will be writing tests to ensure that the HoHoHo API works as expected. You have been given the necessary files to run the API locally (meaning your tests should test the API running on localhost rather than on Heroku). Keep in mind that you will have to modify the HoHoHo codebase to implement proper functionality for certain endpoints.

API Reference: https://github.com/horizons-school-of-technology/week07/tree/master/day1/hohoho#api

API Tests

The following sections will walk you through testing the appropriate endpoints. There are icons next to each test denoting whether the test is provided and whether the test is passing.

Legend:

• ✏️ : Test needs to be written
• 🪲 : Implementation needs to be written

Examples:

• [empty]
  • BOTH the test has been provided and the test passes. So you do not have to write anything (but we advise you to read & understand the test's functionality).
• ✏️
  • The test is not written, so you will have to write it. Once written, the test will pass.
• ✏️ 🪲
  • The test is not written, nor is the test passing. You will have to write the test, and then modify the HoHoHo backend codebase to implement specified functionality.

Before

We have included the following code segment to run before executing every describe block. This means that it will allow you to start every set of tests with a clean slate. As a result, you will have to register/login whenever your tests require a user.

// Delete all data before testing
before(function(done) {
    User.remove()
    .then(function() {
      return Message.remove();
    })
    .then(function() {
      done();
    });
});

Part 1: POST /register

1. Register a User
   • Given a valid username & password, successfully register the user
2. Check if Username exists ✏️
   • Test if user can register without entering a username
3. Check if Password exists ✏️ 🪲
   • Test if user can register without entering a password
4. Prohibit duplicate Usernames ✏️ 🪲
   • Only register the user if the entered username does not exist.
   • Hint: Look at the unique option for Mongoose Schemas

Part 2: POST /login

From now on you will need to use chai.request.agent(app) in order to retain cookies from your login/register requests.

Example:

chai.request.agent(app)
    .post(/* ENDPOINT */)
    .send(/* DATA */)
    .end(function(err, res) {/* CHECK ERROR/STATUS */});

1. Login with correct credentials
   • Given a valid username & password, successfully log in the user
2. Login with incorrect username 🪲
   • User should not be able to log in given an invalid username
   • Write an assertion making sure this requests responds with status 401
3. Login with incorrect password ✏️ 🪲
   • User should not be able to log in given a correct username, but incorrect password
   • Your implementation should respond with status 401 in this case

Part 3: GET /users

You can set chai.request.agent to a variable at the top of your describe block, and use the variable to register/login and perform and future requests that require a logged in user. You can also, in the before block, register a new user and log them in (so that you don't have to do that for every test within the describe block).

Hint

var agent = chai.request.agent(app);
before(function(done) {
    agent
      .post('/register')
      .send({
        YOURUSERNAMEHERE,
        YOURPASSWORDHERE
      })
      .end(function(err, res) {
        // TODO: check for error/success
        // TODO: perform a login request HERE
      });
});

1. Page access requires user to be logged in 🪲
   • Ensure that this page can ONLY be accessed once a user is logged in
   • Note that this test already exists, so your job is merely to implement functionality
2. GET a non-empty list of users ✏️
   • Create an arbitrary number of users (at least one)
   • Test whether GET /users responds with the entire non-empty list of those users
3. BONUS: Limit list to 25 users ✏️ 🪲
   • Create more than 25 users (DO NOT hardcode, find a better way)
   • Modify your implementation so that it only responds with 25 users
   • Test whether GET /users responds with only 25 users

Part 4: POST /messages

1. Page access requires user to be logged in ✏️ 🪲

   • Ensure that this page can ONLY be accessed once a user is logged in

2. Ensure that the to field is required ✏️

   • Write a test to make sure that the to field is required in the POST request

3. Send message to self ✏️

   • You should be able to successfully send a message to yourself
   • How would you get userId for yourself?
   Hint

   You can fine userId in the response body of the POST request to /register

Part 5: GET /messages

1. Page access requires user to be logged in ✏️ 🪲
   • Ensure that this page can ONLY be accessed once a user is logged in
2. BOTH to and from fields are populated ✏️
   • Make sure the to and from fields both contain a username
   • The to & from fields should look like:

     "to": {
       "_id": "TO USER ID HERE",
       "username": "TO USERNAME HERE"
     },
     "from": {
       "_id": "FROM USER ID HERE",
       "username": "FROM USERNAME HERE"
     },

3. Received messages are sorted ✏️ 🪲
   • Test whether the messages from the GET request are in reverse chronological order
4. Include sent messages from logged in user ✏️ 🪲
   • Test whether the messages from the GET request include messages sent from the currently logged in user
5. BONUS: Include messages sent to logged in user ✏️
   • Test whether the messages from the GET request include messages sent to the currently logged in user