Unit Tests about portfolio

[WayneLambert]

Coverage including branches currently sits at 85%

[github-actions]

This issue is stale since it has been open for 10 days without any activity. If the 'Stale Issue' label hasn't been removed or a comment made on the issue, it will be closed after 5 days of inactivity.

[github-actions]

This issue is stale since it has been open for 10 days without any activity. If the 'Stale Issue' label hasn't been removed or a comment made on the issue, it will be closed after 5 days of inactivity.

[WayneLambert]

Code coverage currently sits at 88%.

[github-actions]

This issue is stale since it has been open for 10 days without any activity. If the 'Stale Issue' label hasn't been removed or a comment made on the issue, it will be closed after 5 days of inactivity.

[WayneLambert]

1 failed unit test from commit 9c893c3.

This is an external website link which I have subsequently tested manually. It returns a 200, so I'm happy this is functional.

[WayneLambert]

1 failed unit test from commit b0f8cc2.

This is the same external website link which I have subsequently tested manually. It returns a 200, so I'm happy this is functional.

If it fails once more, I will remove the link and test.

[WayneLambert]

The latest thinking around testing for views is that I should use the rf fixture for testing any GET views since this facilitates easy parametrized tests for both auth and unauth views.

For POST requests, it is better to use the client fixture or even a derived extension of the fixture (see task 2)

Within the conftest.py, make the following changes:

• Change any references to get_user_model() to django_user_model fixture

• Create a fixture similar to auth_user but instead of returning a User object, return a client object that is authenticated. Name this new fixture auth_client. POST request views should be tested with totally separate tests. This approach exposes more methods where I can assert on response content, response url, response's template, redirect_chain, etc.

---

There is also a marker to be aware of which could help tests run that are falsely failing due to a failing template variable.

@pytest.mark.ignore_template_errors

---

Additions of the following django_assert_max_num_queries fixture/assertion could enable me to maintain that my queries are not increasing in number and therefore reducing the speed of my application.

[WayneLambert]

Previously, I had an issue running tests with pytest-xdist. I thought it was something to do with me running my tests within a Docker container, however after reading the CHANGELOG which said:

v3.10.0 (2020-08-25)
Improvements

• Officialy support Django 3.1
• Preliminary supoprt for upcoming Django 3.2
• Support for pytest-xdist 2.0

I can use pytest-xdist with many processors. With optimisations in my tests, I can now run a test suite a 448 tests in 42 seconds.

Run with -n 0 flag if running a small suite and the setup would take longer. This essentially disables pytest-xdist.

[github-actions]

This issue is stale since it has been open for 10 days without any activity. If the 'Stale Issue' label hasn't been removed or a comment made on the issue, it will be closed after 5 days of inactivity.

[WayneLambert]

The GitHub Action for the testing needs to be configured. The tests are running and passing which do not require the database, however the tests seemingly don't have the proper authentication for the test Postgres database. It seems that the environment variables are not set up correctly.

[github-actions]

This issue is stale since it has been open for 10 days without any activity. If the 'Stale Issue' label hasn't been removed or a comment made on the issue, it will be closed after 5 days of inactivity.