When you return all of the videos from endpoint you should add an optional parameter that will change the ordering of the data
/?order=ascand
/?order=descWhen you receive asc the videos should be returned in ascending order by the number of votes. i.e. starting with the lowest number of votes.
When you receive desc the videos should be returned in descending order by the number of votes. i.e. starting with the highest number of votes.
If no parameter is passed, the order should be by ID.
As a further stretch goal consider adding automated unit/integration tests checking that your backend endpoints are working as expected and adhere to the requirements.
We have helped you get started by setting up a test runner for your backend systems and adding a couple tests to server/api.test.js. These tests would check that the list end view endpoints work as expected.
First you need to set up the tests. To do that make sure you create a separate database for tests, for example let's call it videorec_test:
createdb videorec_test
Afterwards edit your .env file and change the TEST_DATABASE_URL to point to this database.
Note: we are using a different database to make sure that we don't accidentally modify your normal database every time that you run your tests.
Once you have set up the database settings you can now run the tests by calling
npm run test:server
Check the response, it will tell you if the tests have succeeded or not. As with the frontend tests it is possible you you will need to update the test to cater for how you have implemented your backend.
The test runner above is set up to have transactional tests. What this means is that whenever you start the testing session the code will reset your (test) database using the initdb.sql you have created in level 200. Afterwards it will run each test in a database transaction, rolling it back at the end of the test. Database transactions are a feature of most relational databases that allow you to run SQL commands in a temporary setting first and only if you are happy with the results will they be saved to the database. We use this feature during test runs as we ask the database to never save our changes at the end of the tests. This allows each test case to start with the exact same, empty database as every other test.
Tests are useful to run every time you create a PR to make sure you don't accidentally add or change code that breaks existing functionality. You can go to .github/workflows/run-server-tests.yml and remove the comment from the line that says pull_request:. This will run the npm run test:server call every time you create a new PR blocking merging in case tests fail.
You might want to add some new test cases. Here are some examples:
- Verify that the videos can be deleted
- Verify that the video rating can be modified up and down