tests package

tests package#

Subpackages#

Submodules#

tests.apps module#

class tests.apps.TestsConfig(app_name, app_module)[source]#

Bases: AppConfig

default_auto_field = 'django.db.models.BigAutoField'#
name = 'tests'#

tests.test_manager module#

class tests.test_manager.CobaltTestManagerAbstract(app=None)[source]#

Bases: ABC

Abstract class to hold things that are common across the two types of testing: Unit testing (single, short tests) and Integration testing (larger, connected stories).

get_user(username)[source]#

Get a user by username

login_test_client(user)[source]#

login user through test client interface

report()[source]#

Report on total test findings

report_html()[source]#

return report as html

run()[source]#
save_results(status, test_name, test_description=None, output=None)[source]#

handle logging results

Parameters:

  • status – Boolean for success or failure OR HTTP Status Code

  • test_name – Str. Name of test (short description)

  • test_description – Str. Explains what this test does in detail (optional)

  • output – Output from test

sleep(duration=99999999)[source]#

Util to sleep for a long time to allow DB to be investigated when there are problems with tests

class tests.test_manager.CobaltTestManagerIntegration(app, browser, base_url, headless, single_test)[source]#

Bases: CobaltTestManagerAbstract

This orchestrates the automated integration tests.

It assumes a fresh database is in place.

Three types of test can be performed:

  1. Internal - using views and models to update and view the data, checking

    for core functionality

  2. Client - using Django’s test client we can access the “screens” through

    an API, interacting with the system through POST and GET. This tests the external interfaces but runs no client side code.

  3. Selenium - Selenium handles the UI tests. These tests interact with

    the UI in the same way as a user would and test both the server and client code, although ugly screens and typos will not be detected. This can also test different browsers.

This class provides basic set up for the tests that are run and collates the results.

To add tests you can copy an existing one. Tests can use any combination of the approaches mentioned above.

login_selenium_user(user)[source]#

login user through browser

login_user(user)[source]#

Login user to both test client and Pylenium

run()[source]#
selenium_wait_for(element_id, timeout=5)[source]#

Wait for element_id to be on page and return it

selenium_wait_for_clickable(element_id, timeout=5)[source]#

Wait for element_id to be clickable and return it. E.g. if element is hidden.

selenium_wait_for_clickable_by_name(element_name, timeout=5)[source]#

Wait for element_name to be clickable and return it.

selenium_wait_for_select_and_pick_an_option(element_id, choice_name, timeout=5)[source]#

Wait for a select to appear and pick an option from it

selenium_wait_for_text(text, element_id, timeout=5)[source]#

Wait for text to appear in element_id.

class tests.test_manager.CobaltTestManagerUnit(app=None)[source]#

Bases: CobaltTestManagerAbstract

Class to handle unit tests

tests.test_manager.run_methods(class_instance)[source]#

copied from stackoverflow - call all methods on class

tests.urls module#

tests.views module#

We needed to do some testing on the htmx search and it seemed useful to add a test url for it

tests.views.button_test(request)[source]#

Test hyperscript button reveal problem

Module contents#

Contents