Return back to the README.md file.
In this section, you need to convince the assessors that you have conducted enough testing to legitimately believe that the site works well. Essentially, in this part, you should go over all of your project's features, and ensure that they all work as intended, with the project providing an easy and straightforward way for the users to achieve their goals.
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
Use the space to discuss code validation for any of your own code files (where applicable). You are not required to validate external libraries/frameworks, such as imported Bootstrap, Materialize, Font Awesome, etc.
IMPORTANT: You must provide a screenshot for each file you validate.
PRO TIP: Always validate the live site pages, not your local code. There could be subtle/hidden differences.
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
I have used the recommended HTML W3C Validator to validate all of my HTML files.
- If you are copying/pasting your HTML code, use this link: https://validator.w3.org/#validate_by_input
- (recommended) If you are using the live deployed site pages, use this link: https://validator.w3.org/#validate_by_uri
It's recommended to validate the live pages (each of them) using the deployed URL. This will give you a custom URL as well, which you can use on your testing documentation. It makes it easier to return back to a page to validate it again in the future. The URL will look something like this:
Sample HTML code validation documentation (tables are extremely helpful!):
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
| Page | W3C URL | Screenshot | Notes |
|---|---|---|---|
| Home | W3C |  |
Section lacks header h2-h6 warning |
| Contact | W3C |  |
obsolete iframe warnings |
| Quiz | W3C |  |
Pass: No Errors |
| Add Blog | n/a |  |
Duplicate IDs found, and fixed |
| Checkout | n/a |  |
Pass: No Errors |
| x | x | x | repeat for all remaining HTML files |
IMPORTANT: Python/Jinja syntax in HTML
Python projects that use Jinja syntax, such as {% for loops %}, {% url 'home' %}, and {{ variable|filter }}
will not validate properly if you're copying/pasting into the HTML validator.
In order to properly validate these types of files, it's recommended to validate by uri from the deployed Heroku pages.
Unfortunately, pages that require a user to be logged-in and authenticated (CRUD functionality), will not work using this method, due to the fact that the HTML Validator (W3C) doesn't have access to login to your pages. In order to properly validate HTML pages with Jinja syntax for authenticated pages, follow these steps:
- Navigate to the deployed pages which require authentication
- Right-click anywhere on the page, and select View Page Source (usually
CTRL+Uor⌘+Uon Mac). - This will display the entire "compiled" code, without any Jinja syntax.
- Copy everything, and use the validate by input method.
- Repeat this process for every page that requires a user to be logged-in/authenticated.
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
I have used the recommended CSS Jigsaw Validator to validate all of my CSS files.
- If you are copying/pasting your HTML code, use this link: https://jigsaw.w3.org/css-validator/#validate_by_input
- (recommended) If you are using the live deployed site, use this link: https://jigsaw.w3.org/css-validator/#validate_by_uri
It's recommended to validate the live site if you only have a single CSS file using the deployed URL. This will give you a custom URL as well, which you can use on your testing documentation. It makes it easier to return back to the page to validate it again in the future. The URL will look something like this:
If you have multiple CSS files, then individual validation by input is recommended for the additional CSS files.
IMPORTANT: Third-Party tools
If you're using extras like Bootstrap, Materialize, Font Awesome, then sometimes the validator will attempt to also validate this code, even if it's not part of your own actual code. You are not required to validate the external libraries or frameworks!
Sample CSS code validation documentation (tables are extremely helpful!):
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
| File | Jigsaw URL | Screenshot | Notes |
|---|---|---|---|
| style.css | Jigsaw |  |
Pass: No Errors |
| checkout.css | n/a |  |
Pass: No Errors |
| x | x | x | repeat for all remaining CSS files |
I have used the recommended JShint Validator to validate all of my JS files.
If using modern JavaScript (ES6) methods, then make sure to include the following line at the very top of every single JavaScript file (this should remain in your files for submission):
/* jshint esversion: 11 */
If you are also including jQuery ($), then the updated format will be:
/* jshint esversion: 11, jquery: true */
This allows the JShint validator to recognize modern ES6 methods, such as:
let, const, template literals, arrow functions (=>), etc.
IMPORTANT: External resources
Sometimes we'll write JavaScript that imports variables from other files, such as an array of questions
from questions.js, which are used within the main script.js file elsewhere.
If that's the case, the JShint validation tool doesn't know how to recognize unused variables
that would normally be imported locally in your code.
These warnings are acceptable to showcase on your screenshots.
The same thing applies when using external libraries such as Stripe, Leaflet, Bootstrap, Materialize, etc.. To instantiate these components, we need to use their respective declarator. Again, the JShint validation tool would flag these as undefined/unused variables. These warnings are acceptable to showcase on your screenshots.
Sample JS code validation documentation (tables are extremely helpful!):
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
| File | Screenshot | Notes |
|---|---|---|
| script.js |  |
Unused variables from external files |
| questions.js |  |
Pass: No Errors |
| quiz.js |  |
Unused variables from external files |
| stripe_elements.js |  |
Undefined Stripe variable |
| x | x | x |
The CI Python Linter can be used two different ways.
- Copy/Paste your Python code directly into the linter.
- As an API, using the "raw" URL appended to the linter URL.
- To find the "raw" URL, navigate to your file directly on the GitHub repo.
- On that page, GitHub provides a button on the right called "Raw" that you can click on.
- From that new page, copy the full URL, and paste it after the CI Python Linter URL (with a
/separator). - Check the example table below for a live demo.
It's recommended to validate each file using the API URL. This will give you a custom URL which you can use on your testing documentation. It makes it easier to return back to a file to validate it again in the future. Use the steps above to generate your own custom URLs for each Python file.
IMPORTANT: E501 line too long errors
You must strive to fix any Python lines that are too long ( >80 characters ).
In rare cases where you cannot break the lines [without breaking the functionality],
then by adding # noqa to the end of those lines will ignore linting validation.
# noqa = NO Quality Assurance
NOTE: You must include 2 spaces before the #, and 1 space after the #.
Do not use # noqa all over your project just to clear down validation errors!
This can still cause a project to fail, for failing to fix actual PEP8 validation errors.
Sometimes strings or variables get too long, or long if conditional statements.
These are acceptable instances to use the # noqa.
When trying to fix "line too long" errors, try to avoid using / to split lines.
A better approach would be to use any type of opening bracket, and hit Enter just after that.
Any opening bracket type will work: (, [, {.
By using an opening bracket, Python knows where to appropriately indent the next line of code, without having to "guess" yourself and attempt to tab to the correct indentation level.
Sample Python code validation documentation below (tables are extremely helpful!).
Note: This gives examples of PP3 (Python-only), and Flask/Django files, so eliminate the ones not applicable to your own project.
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
I have used the recommended PEP8 CI Python Linter to validate all of my Python files.
| File | CI URL | Screenshot | Notes |
|---|---|---|---|
| run.py | PEP8 CI |  |
W291 trailing whitespace |
| settings.py | PEP8 CI |  |
E501 line too long |
| Blog views.py | PEP8 CI |  |
Pass: No Errors |
| Checkout urls.py | PEP8 CI |  |
W292 no newline at end of file |
| Profiles models.py | PEP8 CI |  |
Pass: No Errors |
| x | x | x | repeat for all remaining Python files |
IMPORTANT: Django settings.py
The Django settings.py file comes with 4 lines that are quite long, and will throw the E501 line too long error.
This is default behavior, but can be fixed by adding # noqa to the end of those lines.
Example:
AUTH_PASSWORD_VALIDATORS = [
{
"NAME": "django.contrib.auth.password_validation.UserAttributeSimilarityValidator", # noqa
},
{
"NAME": "django.contrib.auth.password_validation.MinimumLengthValidator", # noqa
},
{
"NAME": "django.contrib.auth.password_validation.CommonPasswordValidator", # noqa
},
{
"NAME": "django.contrib.auth.password_validation.NumericPasswordValidator", # noqa
},
]IMPORTANT: migration and pycache files
You do not have to ever validate files from the migrations/ or pycache/ folders!
Ignore these .py files, and validate just the files that you've created or modified.
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
Use this space to discuss testing the live/deployed site on various browsers.
Consider testing at least 3 different browsers, if available on your system.
Recommended browsers to consider:
IMPORTANT: You must provide screenshots of the tested browsers, to "prove" that you've actually tested them.
Please note, there are services out there that can test multiple browser compatibilities at the same time. Some of these are paid services, but some are free. If you use these, you must provide a link to the source used for attribution, and multiple screenshots of the results.
Sample browser testing documentation:
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
I've tested my deployed project on multiple browsers to check for compatibility issues.
| Browser | Screenshot | Notes |
|---|---|---|
| Chrome |  |
Works as expected |
| Firefox |  |
Works as expected |
| Edge |  |
Works as expected |
| Safari |  |
Minor CSS differences |
| Brave |  |
Works as expected |
| Opera |  |
Minor differences |
| Internet Explorer |  |
Does not work as expected |
| x | x | repeat for any other tested browsers |
Use this space to discuss testing the live/deployed site on various device sizes.
The minimum requirement is for the following 3 tests:
- Mobile
- Tablet
- Desktop
IMPORTANT: You must provide screenshots of the tested responsiveness, to "prove" that you've actually tested them.
Using the "amiresponsive" mockup image (or similar) does not suffice the requirements. Consider using some of the built-in device sizes in the Developer Tools.
If you have tested the project on your actual mobile phone or tablet, consider also including screenshots of these as well. It showcases a higher level of manual tests, and can be seen as a positive inclusion!
Sample responsiveness testing documentation:
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
I've tested my deployed project on multiple devices to check for responsiveness issues.
| Device | Screenshot | Notes |
|---|---|---|
| Mobile (DevTools) |  |
Works as expected |
| Tablet (DevTools) |  |
Works as expected |
| Desktop |  |
Works as expected |
| XL Monitor |  |
Scaling starts to have minor issues |
| 4K Monitor |  |
Noticeable scaling issues |
| Google Pixel 7 Pro |  |
Works as expected |
| iPhone 14 |  |
Works as expected |
| x | x | repeat for any other tested sizes |
Use this space to discuss testing the live/deployed site's Lighthouse Audit reports. Avoid testing the local version (especially if developing in Gitpod), as this can have knock-on effects of performance.
If you don't have Lighthouse in your Developer Tools, it can be added as an extension.
Don't just test the home page (unless it's a single-page application). Make sure to test the Lighthouse Audit results for all of your pages.
IMPORTANT: You must provide screenshots of the results, to "prove" that you've actually tested them.
Sample Lighthouse testing documentation:
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
I've tested my deployed project using the Lighthouse Audit tool to check for any major issues.
| Page | Size | Screenshot | Notes |
|---|---|---|---|
| Home | Mobile |  |
Some minor warnings |
| Home | Desktop |  |
Few warnings |
| About | Mobile |  |
Some minor warnings |
| About | Desktop |  |
Few warnings |
| Gallery | Mobile |  |
Slow response time due to large images |
| Gallery | Desktop |  |
Slow response time due to large images |
| x | x | x | repeat for any other tested pages/sizes |
Defensive programming (defensive design) is extremely important!
When building projects that accept user inputs or forms, you should always test the level of security for each. Examples of this could include (not limited to):
Forms:
- Users cannot submit an empty form
- Users must enter valid email addresses
PP3 (Python-only):
- Users must enter a valid letter/word/string when prompted
- Users must choose from a specific list only
Flask/Django:
- Users cannot brute-force a URL to navigate to a restricted page
- Users cannot perform CRUD functionality while logged-out
- User-A should not be able to manipulate data belonging to User-B, or vice versa
- Non-Authenticated users should not be able to access pages that require authentication
- Standard users should not be able to access pages intended for superusers
You'll want to test all functionality on your application, whether it's a standard form,
or uses CRUD functionality for data manipulation on a database.
Make sure to include the required attribute on any form-fields that should be mandatory.
Try to access various pages on your site as different user types (User-A, User-B, guest user, admin, superuser).
You should include any manual tests performed, and the expected results/outcome.
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
Defensive programming was manually tested with the below user acceptance testing:
| Page | User Action | Expected Result | Pass/Fail | Comments |
|---|---|---|---|---|
| Home Page | ||||
| Click on Logo | Redirection to Home page | Pass | ||
| Click on Home link in navbar | Redirection to Home page | Pass | ||
| Gallery Page | ||||
| Click on Gallery link in navbar | Redirection to Gallery page | Pass | ||
| Load gallery images | All images load as expected | Pass | ||
| Contact Page | ||||
| Click on Contact link in navbar | Redirection to Contact page | Pass | ||
| Enter first/last name | Field will accept freeform text | Pass | ||
| Enter valid email address | Field will only accept email address format | Pass | ||
| Enter message in textarea | Field will accept freeform text | Pass | ||
| Click the Submit button | Redirects user to form-dump | Pass | User must click 'Back' button to return | |
| Sign Up | ||||
| Click on Sign Up button | Redirection to Sign Up page | Pass | ||
| Enter valid email address | Field will only accept email address format | Pass | ||
| Enter valid password (twice) | Field will only accept password format | Pass | ||
| Click on Sign Up button | Asks user to confirm email page | Pass | Email sent to user | |
| Confirm email | Redirects user to blank Sign In page | Pass | ||
| Log In | ||||
| Click on the Login link | Redirection to Login page | Pass | ||
| Enter valid email address | Field will only accept email address format | Pass | ||
| Enter valid password | Field will only accept password format | Pass | ||
| Click Login button | Redirects user to home page | Pass | ||
| Log Out | ||||
| Click Logout button | Redirects user to logout page | Pass | Confirms logout first | |
| Click Confirm Logout button | Redirects user to home page | Pass | ||
| Profile | ||||
| Click on Profile button | User will be redirected to the Profile page | Pass | ||
| Click on the Edit button | User will be redirected to the edit profile page | Pass | ||
| Click on the My Orders link | User will be redirected to the My Orders page | Pass | ||
| Brute forcing the URL to get to another user's profile | User should be given an error | Pass | Redirects user back to own profile |
Repeat for all other tests, as applicable to your own site. The aforementioned tests are just an example of a few different project scenarios.
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
Testing user stories is actually quite simple, once you've already got the stories defined on your README.
Most of your project's features should already align with the user stories, so this should as simple as creating a table with the user story, matching with the re-used screenshot from the respective feature.
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
| User Story | Screenshot |
|---|---|
| As a new site user, I would like to ____________, so that I can ____________. |  |
| As a new site user, I would like to ____________, so that I can ____________. |  |
| As a new site user, I would like to ____________, so that I can ____________. |  |
| As a returning site user, I would like to ____________, so that I can ____________. |  |
| As a returning site user, I would like to ____________, so that I can ____________. |  |
| As a returning site user, I would like to ____________, so that I can ____________. |  |
| As a site administrator, I should be able to ____________, so that I can ____________. |  |
| As a site administrator, I should be able to ____________, so that I can ____________. |  |
| As a site administrator, I should be able to ____________, so that I can ____________. |  |
| repeat for all remaining user stories | x |
I have conducted a series of automated tests on my application.
I fully acknowledge and understand that, in a real-world scenario, an extensive set of additional tests would be more comprehensive.
Adjust the code below (file names, etc.) to match your own project files/folders.
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
I have used the Jest JavaScript testing framework to test the application functionality.
In order to work with Jest, I first had to initialize NPM.
npm init- Hit
enterfor all options, except for test command:, just typejest.
Add Jest to a list called Dev Dependencies in a dev environment:
npm install --save-dev jest
IMPORTANT: Initial configurations
When creating test files, the name of the file needs to be file-name.test.js in order for Jest to properly work.
Due to a change in Jest's default configuration, you'll need to add the following code to the top of the .test.js file:
/**
* @jest-environment jsdom
*/
const { test, expect } = require("@jest/globals");
const { function1, function2, function3, etc. } = require("../script-name");
beforeAll(() => {
let fs = require("fs");
let fileContents = fs.readFileSync("index.html", "utf-8");
document.open();
document.write(fileContents);
document.close();
});Remember to adjust the fs.readFileSync() to the specific file you'd like you test.
The example above is testing the index.html file.
Finally, at the bottom of the script file where your primary scripts are written, include the following at the bottom of the file.
Make sure to include the name of all of your functions that are being tested in the .test.js file.
if (typeof module !== "undefined") module.exports = {
function1, function2, function3, etc.
};Now that these steps have been undertaken, further tests can be written, and be expected to fail initially. Write JS code that can get the tests to pass as part of the Red-Green refactor process.
Once ready, to run the tests, use this command:
npm test
NOTE: To obtain a coverage report, use the following command:
npm test --coverage
Below are the results from the tests that I've written for this application:
| Test Suites | Tests | Coverage | Screenshot |
|---|---|---|---|
| 1 passed | 16 passed | 55% |  |
| x | x | x | repeat for all remaining tests |
Use this section to list any known issues you ran into while writing your Jest tests. Remember to include screenshots (where possible), and a solution to the issue (if known).
This can be used for both "fixed" and "unresolved" issues.
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
Adjust the code below (file names, etc.) to match your own project files/folders.
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
I have used Django's built-in unit testing framework to test the application functionality.
In order to run the tests, I ran the following command in the terminal each time:
python3 manage.py test name-of-app
To create the coverage report, I would then run the following commands:
coverage run --source=name-of-app manage.py test
coverage report
To see the HTML version of the reports, and find out whether some pieces of code were missing, I ran the following commands:
coverage html
python3 -m http.server
Below are the results from the various apps on my application that I've tested:
| App | File | Coverage | Screenshot |
|---|---|---|---|
| Bag | test_forms.py | 99% |  |
| Bag | test_models.py | 89% |  |
| Bag | test_urls.py | 100% |  |
| Bag | test_views.py | 71% |  |
| Checkout | test_forms.py | 99% |  |
| Checkout | test_models.py | 89% |  |
| Checkout | test_urls.py | 100% |  |
| Checkout | test_views.py | 71% |  |
| Home | test_forms.py | 99% |  |
| Home | test_models.py | 89% |  |
| Home | test_urls.py | 100% |  |
| Home | test_views.py | 71% |  |
| Products | test_forms.py | 99% |  |
| Products | test_models.py | 89% |  |
| Products | test_urls.py | 100% |  |
| Products | test_views.py | 71% |  |
| Profiles | test_forms.py | 99% |  |
| Profiles | test_models.py | 89% |  |
| Profiles | test_urls.py | 100% |  |
| Profiles | test_views.py | 71% |  |
| x | x | x | repeat for all remaining tested apps/files |
Use this section to list any known issues you ran into while writing your unit tests. Remember to include screenshots (where possible), and a solution to the issue (if known).
This can be used for both "fixed" and "unresolved" issues.
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
It's very important to document any bugs you've discovered while developing the project. Make sure to include any necessary steps you've implemented to fix the bug(s) as well.
For JavaScript and Python applications, it's best to screenshot the errors to include them as well.
PRO TIP: screenshots of bugs are extremely helpful, and go a long way!
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
-
JS Uncaught ReferenceError:
foobaris undefined/not defined
- To fix this, I _____________________.
-
JS
'let'or'const'or'template literal syntax'or'arrow function syntax (=>)'is available in ES6 (use'esversion: 11') or Mozilla JS extensions (use moz).
- To fix this, I _____________________.
-
Python
'ModuleNotFoundError'when trying to import module from imported package
- To fix this, I _____________________.
-
Django
TemplateDoesNotExistat /appname/path appname/template_name.html
- To fix this, I _____________________.
-
Python
E501 line too long(93 > 79 characters)- To fix this, I _____________________.
An improved way to manage bugs is to use the built-in Issues tracker on your GitHub repository. To access your Issues, click on the "Issues" tab at the top of your repository. Alternatively, use this link: https://github.com/Alena18/VictoriaBakeryBlog/issues
If using the Issues tracker for your bug management, you can simplify the documentation process. Issues allow you to directly paste screenshots into the issue without having to first save the screenshot locally, then uploading into your project.
You can add labels to your issues (bug), assign yourself as the owner, and add comments/updates as you progress with fixing the issue(s).
Once you've sorted the issue, you should then "Close" it.
When showcasing your bug tracking for assessment, you can use the following format:
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
Fixed Bugs
All previously closed/fixed bugs can be tracked here.
Open Issues
Any remaining open issues can be tracked here.
You will need to mention unfixed bugs and why they were not fixed. This section should include shortcomings of the frameworks or technologies used. Although time can be a big variable to consider, paucity of time and difficulty understanding implementation is not a valid reason to leave bugs unfixed.
If you've identified any unfixed bugs, no matter how small, be sure to list them here. It's better to be honest and list them, because if it's not documented and an assessor finds the issue, they need to know whether or not you're aware of them as well, and why you've not corrected/fixed them.
Some examples:
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
-
On devices smaller than 375px, the page starts to have
overflow-xscrolling.
- Attempted fix: I tried to add additional media queries to handle this, but things started becoming too small to read.
-
For PP3, when using a helper
clear()function, any text above the height of the terminal does not clear, and remains when you scroll up.
- Attempted fix: I tried to adjust the terminal size, but it only resizes the actual terminal, not the allowable area for text.
-
When validating HTML with a semantic
sectionelement, the validator warns about lacking a headerh2-h6. This is acceptable.
- Attempted fix: this is a known warning and acceptable, and my section doesn't require a header since it's dynamically added via JS.
If you legitimately cannot find any unfixed bugs or warnings, then use the following sentence:
🛑🛑🛑🛑🛑 END OF NOTES (to be deleted) 🛑🛑🛑🛑🛑
There are no remaining bugs that I am aware of.