09. Progress & Learning Tracker

Weds, 10 Feb

• Lucy: initially had problems with the app not adding food or walks. The initial post worked, but all subsequent ones failed. It transpired that our app doesn't work on Firefox! Loaded the webpage in Chromium and all okay.
• Melissa: wrote a dummy failing test, but encountered this error "Creating test database for alias 'default'... Got an error creating the test database: permission denied to create database". Going into PSQL and adding this command ALTER USER postgres CREATEDB; worked. Thank you to StackOverflow.

Thurs, 11 Feb

• Georgie: We wanted to start with a test for something which wasn't dependent on anything so we chose the pack model. I used this testing tutorial to help guide us and we managed to get a passing test! To get the test for our unique code generator we stubbed it using seeded randomness, which was explained in the W3 tutorial
• Mel: We used this tutorial to understand what we need to test and learned that we need to test our views. You should test all aspects of your own code, but not any libraries or functionality provided as part of Python or Django.

Useful Links: https://medium.com/plusteam/pytest-beginners-guide-9fb9451706bf https://www.youtube.com/watch?v=_rLPDxpXIFc https://www.obeythetestinggoat.com/book/chapter_post_and_database.html https://realpython.com/testing-in-django-part-1-best-practices-and-examples/#testing-models https://www.w3schools.com/python/ref_random_seed.asp

Fri, 12 Feb

• Lucy: Using the coverage html report we established that the area of lowest coverage was the view.py file, where our business logic is stored. We initially wrote tests for 'JoinPackView', covering the three possible scenarios for joining a pack: no pack code entered, invalid code entered or valid code entered. We used this testing article to understand the format of the tests.
• Mel: Added a passing test that checks the Create Food View returns an error message if food is added to the log with invalid data. Next step is to test the food is stored successfully in the database but as this is linked to the pack_id foreign key which comes from the session, we need to research further.

Mon, 15 Feb

• Georgie: (added tests for Bad Request responses)
• Lucy: Used Django docs to work out how to mock sessions, Django docs to set fed_at as a default time in the model, and FreezeGun library to mock time, meaning that we were able to test adding a meal.

Wed, 17 Feb

• Mel: Updated README and wrote a passing test for GetFood if incorrect code provided.

Thurs, 18 Feb

Mon, 22 Feb Mel: We dedicated the full day to writing tests with the aim of getting to 100% coverage for our backend. Have successful passing tests for Food Class, it was simple to replicate it for Walks. Creating a Pack, Joining, Leaving and Getting a Pack were more challenging and we didn't find many useful resources to help us. The main issue was sessions, how to stub it, or how to interpolate the session key into the data being returned. We eventually solved this with the help of Tris and Simo. We changed how our data was returned from a b string to a JSON object which allowed us to interpolate the data.

---

How we generated a random room code: We imported the 'random' and 'string' modules at the top of our file. We then defined our function, and set the variable 'length' to 6. We started by asking the function to run while true. We set the variable code equal to an empty string that we called 'join' method that needs a parameter which needs to be an iterable object where all the returned values are strings. The parameter was the random module with choices() that returns a list with a random selection from the sequence of upper case letters from A to Z with the length equal to 6. To ensure the code is unique we filtered all our Pack objects by code and checked that the count of the list of objects returned is 0. If it is 0, we break out of the loop and return the code.