Testing

Testing

We have tests for front end and back end alike. While we neglected them at first, we quickly became aware of this and payed more attention to them later on, even though more complex and thorough tests could exist.

Back end

Our back end utilizes supertest, with which we make sure our CRUD operations work as they should. For example, in 'src/tests/bone_api.test.js', starting at line 17, we have a test that gets all content from URL '/api/bones'. This should be successful (status code 200) and the content type should be JSON, so we make sure this is the case. Also, we have all our bones in 'bonesInDatabase', as we're using 'bonesInDb()', a function defined in 'bone_test_helper.js', to fetch them. We want /api/bones to return ALL our bones, so we're checking if the number of returned bones is equal to that of bones in bonesInDatabase. Additionally, each name found in the response should also be found in bonesInDatabase, we're checking this as well.

Our back end tests typically check that the appropriate status code is returned and that the number of items in our test database either increases, decreases or stays the same depending on which operation we are testing. If we're testing deletion, our database should obviously contain fewer items after a successful deletion. Also, you shouldn't be able to do anything with an item of an invalid ID; a status code signifying that something went wrong should be returned. We have, to the best of our ability, made sure that what shouldn't be done, can't be done (can't login with bad username/password combo, can't choose a password that's too short, stuff like that).

Front end

When it comes to our front end, we have fiddled with various modules and libraries. Enzyme is used to make sure that when going to certain pages, the appropriate elements are rendered. With enzyme's 'shallow', we get to check whether or not the component we are testing renders all the input fields, text fields, divs, components etc. that it should.

Our more prominent method of testing is with the puppeteer library. For example, in 'src/__test__/WritingGame.puppeteer.test.js' we are actually launching the application on our test port, navigating from page to page by finding elements such as buttons by their IDs, and playing a short game and always giving "testivastaus" as an input. After the appropriate number of rounds, we make sure we end up on the end screen, by checking that certain text elements can be found in the content of the page we're currently on. So, puppeteer allows us to test how our game functions, which we do not use enzyme for.