Closes #633 Tests not passing locally but are in CI - updated

[anettleship]

Replaces #664

This pull request pulls from a new branch added as GeekZoneHQ/web:doc-633-tests_not_passing_locally, instead of my own forked repository used in the previous pull request: anettleship/GeekZone-web-adrian/tree/doc-633-tests_not_passing_locally. In the previous PR we ran into a CircleCI issue because I had issued the pull request from my own github account rather than a added within GeekZoneHQ/web.

--

Problem:
When running python3 manage.py test locally in WSL, it runs all 33 tests but FAILED (failures=1, errors=6)
The same tests are all passing in CircleCI.

Solution
Amend project readme.md file, where dev set up is documented, to instruct user to create test user environment variables for TEST_USER_PASSWORD and TEST_USER_PASSWORD_BAD in web/.env to align with values currently present in web/.env.dev.

The readme directs the user to create a file at web/.env with the following commands listed below. These do not currently create the two environment variables and values:

TEST_USER_PASSWORD=k38m1KIhIUzeA^UL
TEST_USER_PASSWORD_BAD=password

When tests run locally, these environment variables are null. This caused the errors reported in the bug report (failures=1, errors=6). For the failing test: test_signed_in_users_cannot_register, the test failed as it was unable to login successfully with a null password, so after failing to log in, the test was able to register a new user, so it returned http 200 for success rather than the 302 redirect.

I have amended the two commands provided in the readme that create the .env file for unix and windows users from and to...

Windows Before:

echo "DEBUG=1
DATABASE_USER=postgres
DATABASE_NAME=postgres
DATABASE_HOST=localhost
DATABASE_PASSWORD=postgres
DATABASE_PORT=5432" | tee web/.env

Windows After:

echo "DEBUG=1
DATABASE_USER=postgres
DATABASE_NAME=postgres
DATABASE_HOST=localhost
DATABASE_PASSWORD=postgres
DATABASE_PORT=5432
TEST_USER_PASSWORD=k38m1KIhIUzeA^UL
TEST_USER_PASSWORD_BAD=password" | tee web/.env

Unix Before:

cat < web/.env
DEBUG=1
DATABASE_USER=postgres
DATABASE_NAME=postgres
DATABASE_HOST=localhost
DATABASE_PASSWORD=postgres
DATABASE_PORT=5432
EOF

Unix After:

cat < web/.env
DEBUG=1
DATABASE_USER=postgres
DATABASE_NAME=postgres
DATABASE_HOST=localhost
DATABASE_PASSWORD=postgres
DATABASE_PORT=5432
TEST_USER_PASSWORD=k38m1KIhIUzeA^UL
TEST_USER_PASSWORD_BAD=password
EOF

Related Issue

#633

Motivation and Context

Tests were failing, now they pass.

How Has This Been Tested?

I've tested this fully on Linux to determine that the tests fail in the expected places following the readme and using the first command, but when the .env file is created with the amended command instead - i.e. the two new environment variable are present in web/.env, all tests pass.

On Windows I have tested the powershell command to ensure that the .env file is created correctly with the additional lines, but I have not set up the project and run the tests.

Types of changes

• Bug fix (non-breaking change which fixes an issue) - change to documentation only
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes - no new code.
• All new and existing tests passed.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[anettleship]

Closing this PR as although it is now a branch on GeekZoneHQ/web, it was formed by pushing files from my forked repo in my own github account back to GeekZoneHQ/web, where we should only clone directly from GeekZoneHQ/web and push back to it, rather than using a forked repository. This is because the workflow that involves forking the project into our own account can result in leaked secrets for our usecase; it is prohibited by CircleCI as a result.