Generated HTML and CSS code were validated with the W3C Markup and CSS validators. Both were found to have no errors or warnings. Reports can be seen below:
CSS
- style.css - Global style sheet
- login.css - Login page style sheet
- recipe.css - Recipe and add/edit recipe pages style sheet
- search.css - Search page style sheet
JavaScript code was run through JSHint to ensure they were syntactically correct. Any errors were corrected and linting re-run until correct.
Pylint was used to verify Python code. Any errors were corrected and re-run until correct. Reports can be seen below:
app.py report
************* Module app
app.py:17:4: W0611: Unused import env (unused-import)
------------------------------------------------------------------
Your code has been rated at 9.95/10 (previous run: 9.95/10, +0.00)A warning regarding unused-imports remains as the linter is unable to recognise the use of variables in env.py.
decorators.py report
--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)helpers.py report
--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)Google Chrome's lighthouse was also run and provided the following reports:
Home page
login page
recipe page
edit recipe page
profile page
search page
Automated unit testing was performed on functions suitable for it:
- calculate_rating
- encode_time
- calculate_pages
Automated tests also check correct behaviour from the flask app routes:
- home
- search
- recipe
- profile
- register
- login
- logout
- add_recipe
To perform automated testing, from the project root directory type:
python test.py
Note: running route tests requires database access credentials.
>python test.py
test_add_recipe (__main__.TestApp) ... ok
test_login (__main__.TestApp) ... ok
test_logout (__main__.TestApp) ... ok
test_mainpage (__main__.TestApp) ... ok
test_profile (__main__.TestApp) ... ok
test_recipe (__main__.TestApp) ... ok
test_registration (__main__.TestApp) ... ok
test_search (__main__.TestApp) ... ok
test_calculate_pages (__main__.TestHelpers) ... ok
test_calculate_rating (__main__.TestHelpers) ... ok
test_encode_time (__main__.TestHelpers) ... ok
----------------------------------------------------------------------
Ran 11 tests in 12.686s
OK
Primary iterative testing was undertaken on a Windows 10 desktop machine with the Google Chrome browser. Once a feature was considered complete it was tested in other environments.
Desktop testing
- Platforms:
- Custom Desktop (Windows 10, Fedora 33)
- Microsoft SurfaceBook 2 (Windows 10)
- Apple MacBook Air M1 (macOS Big Sur 11.2.2)
- Browsers:
- Google Chrome/Chromium
- Microsoft Edge
- Firefox
- Opera
- Safari
Tablet testing
- Platforms:
- Lenovo Tab M10 (Android 10)
- Browsers:
- Google Chrome
- Firefox
- Opera
Mobile testing
- Platforms:
- OnePlus7 (Android 10)
- Samsung Galaxy J6 (Android 10)
- Browsers:
- Chrome
- FireFox
- Opera
Code changes were tested prior to committing and pushing to github on the local machine. This was in an attempt to prevent faulty or broken code from being pushed to the repository or deployed to the live site. Further, new features were pushed to a separate branch, which wasn't merged to main and deployed to the live site until tested. On occasions where bugs were missed in testing an issue was opened on github if appropriate. Issues were not raised for bugs arising from known feature incomplete code committed to github, as this information was captured in the coding to-do lists. This approach kept most bugs from being uploaded, with only a few cases of bugs either too complex to be fixed for the current release, or those that introduced regressions in existing code being uploaded.
Manual unit testing was conducted iteratively by attempting to "break" new code. In this way most bugs were caught and fixed before committing to the repository and live site.
The python print() and JavaScript console.log functions were used to output variable values and breakpoints during development to give hints to where faults were occurring and why.
Final UI testing was conducted prior to submission to confirm the UI fulfilled the required user stories:
The project was submitted for peer review on the code institute slack channel.
A Final sanity check was done with the student check list to ensure the site fits submission guidelines.
404 when opening login page when user logged in
Link. If a user is already logged in and tries to open the login page the website raises a 404 error.
Cause
Missing url_for in redirect
Resolution
Fix: Fixes 404 error from login page when user already logged in
Recipe page layout broken on small screens
Link. Page layout breaks when using Google Chrome's responsive layout test.
Cause
Fault in either Google Chrome or Materialize.
Resolution
Not applicable.
Exception on registering new user
Link. Exception raised when registering new user.
Cause
User not being added properly to session cookie after registration.
Resolution
Admin editing another users recipe changes recipe author
Link. Admin user overwrites original author field.
Cause
Author field overwritten when updating recipe record
Resolution
On refresh horizontal scroller is offset vertically by to bottom of the page
Link. Firefox offsets contents.
Cause
Scroll-item being set to 100% height.
Resolution
Using the time picker in the search form gives an error message
[Link](#32). The following error is displayed in the console when using the time-picker component: `[Intervention] Unable to preventDefault inside passive event listener due to target being treated as passive.` **Cause**Appears to be issue within materialize. Possibly using a passive scroll event listener.
Resolution
Not Applicable
Wrong dropdown items selected on IOS
Link. Materialize select control selects incorrect options when using IOS.
Cause
Appears to be a materialize bug. Missed as no IOS hardware was available for testing, problem doesn't seem to appear when using browser stack.
Resolution
Converted select items to system default with custom styling to fit site design. Fixed in commit c9174f2.
Flash messages appear under recipe admin panel buttons
[Link](#39). Flash messages appear beneath recipe admin buttons.Cause
Flash messages given too low a z-index.
Resolution
Flash message z-index increased to 5. Fixed in commit: 0528c8b
A number of the lighthouse reports flag issues with slow performance, mostly stemming from downloading large recipe image files. Cloudinary offers features for responsive image uploading which could be used to mitigate this.
The current automatic unit testing tests routes with the live database. This potentially could allow testing records to be left in the live database. A better approach would be to patch the database during tests to use a testing database of a mock database such as mongomock.