-
W3C's Markup Validation Service was used to test the validity of all HTML used in this project. The code was validated by direct input, and all suggested corrections were then made. As a result, all of the site's HTML source code now returns a "Document checking completed. No errors or warnings to show." message upon being passed through this validator, as is reflected in the following screenshot:
-
Likewise, the website's custom CSS stylesheet was checked for errors using W3C's CSS Validation Service. Once again, validation by direct input was the preferred method selected, and all necessary changes were subsequently carried out. Consequently, the stylesheet now returns a "Congratulations! No error found." message upon being passed through this validator, as the following screenshot indicates:
-
The issue surrounding the incompatibility of
backdrop-filterwith the W3C validator appears to be a well documented one. However, given that this property is present in the MDN Docs and endorsed by CSS-Tricks, it has been used in this project in spite of the validator's error messages. Its patchy browser support necessitated the use of a@supportsquery on line 698 of the project's stylesheet (with a reasonable fallback option of an opaque background), as suggested in this CSS-Tricks article -
In a similar manner, all of the site's custom JavaScript/JSX files were validated against JSHint's error-detection tool, which is available both as an online linter and an IDE extension for real-time JS problem-solving. After heeding various warning and error messages, at the time of deployment each of these .js documents passed JSHint validation with just a handful of warnings detected.
 |
 |
 |
- All testing was performed manually, and on a near-constant basis as the project evolved. Google Chrome DevTools served as an indispensable resource throughout this testing process, allowing incremental adjustments to be made to the site's infrastructure and layout. In addition, the React Developer Tools DevTools extension was consulted extensively to inspect the internal hierarchies and structure of the app's component tree. The site's responsiveness was also closely monitored and rigorously tested from start to finish using the developer-oriented Responsively App browser.
| Devices | ||||||
|---|---|---|---|---|---|---|
| Samsung Galaxy S5 |  |
 |
 |
 |
 |
 |
| Huawei P20 |  |
 |
 |
 |
 |
 |
| Moto G4 |  |
 |
 |
 |
 |
 |
| Kindle Fire HD |  |
 |
 |
 |
 |
 |
| MacBook Pro |  |
 |
 |
 |
 |
|
| Acer ΛSPIRE |  |
 |
 |
 |
 |
|
| Android Smart TV |  |
 |
 |
 |
 |
 |
| Browsers | ||||||
|---|---|---|---|---|---|---|
 |
 |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
|
 |
|
|
|
|
|
|
 |
 |
 |
 |
 |
 |
|
 |
|
|
|
|
|
-
A broad selection of physical devices were used to test real-life responsiveness. These ranged in size from a Samsung Galaxy S5 (screen width 360px) right up to a JVC 32" LED Android Smart TV (using this device's native Odin browser/ADK). Other devices used in testing included the Moto G4 and Huawei P20 smartphones, a Kindle Fire HD tablet, an Acer ΛSPIRE F15 Windows laptop and a 13" MacBook Pro.
-
In addition to Chrome, Firefox and the emerging Odin smart TV browser, the site was also viewed numerous times in the Safari, Microsoft Edge and Amazon Silk browsers prior to completion.