@ -41,7 +41,7 @@ Updates to python modules will need to be captured with SCM. This can be done by
|
||||
!!! danger "Requirement"
|
||||
All models **are** to have tests written for them, Including testing between dependent models.
|
||||
|
||||
See [Documentation](https://nofusscomputing.com/projects/django-template/development/api/tests/) for further information
|
||||
See [Documentation](https://nofusscomputing.com/projects/django-template/development/testing/) for further information
|
||||
|
||||
|
||||
## Docker Container
|
||||
|
||||
@ -1,116 +1,11 @@
|
||||
---
|
||||
title: Unit Tests
|
||||
title: Test Cases
|
||||
description: No Fuss Computings django itsm unit tests
|
||||
date: 2024-06-15
|
||||
template: project.html
|
||||
about: https://gitlab.com/nofusscomputing/infrastructure/configuration-management/django_app
|
||||
---
|
||||
|
||||
Unit tests are written to aid in application stability and to assist in preventing regression bugs. As part of development the developer working on a Merge/Pull request is to ensure that tests are written. Failing to do so will more likely than not ensure that your Merge/Pull request is not merged.
|
||||
|
||||
|
||||
## Writing Tests
|
||||
|
||||
We use class based tests. Each class will require a `setUpTestData` method for test setup. To furhter assist in the writing of tests, we have written the test cases for common items as an abstract class. You are advised to review the [test cases](#test-cases) and if it's applicable to the item you have added, than add the test case class to be inherited by your test class.
|
||||
|
||||
naming of test classes is in `CamelCase` in format `<Model Name><what's being tested>` for example the class name for device model history entry tests would be `DeviceHistory`.
|
||||
|
||||
Test setup is written in a method called `setUpTestData` and is to contain the setup for all tests within the test class.
|
||||
|
||||
Example of a model history test class.
|
||||
|
||||
``` py
|
||||
|
||||
import pytest
|
||||
import unittest
|
||||
import requests
|
||||
|
||||
from django.test import TestCase, Client
|
||||
|
||||
from core.models.history import History
|
||||
from core.tests.abstract.history_entry import HistoryEntry
|
||||
from core.tests.abstract.history_entry_parent_model import HistoryEntryParentItem
|
||||
|
||||
|
||||
|
||||
class DeviceHistory(TestCase, HistoryEntry, HistoryEntryParentItem):
|
||||
|
||||
|
||||
model = Device
|
||||
|
||||
|
||||
@classmethod
|
||||
def setUpTestData(self):
|
||||
""" Setup Test """
|
||||
|
||||
```
|
||||
|
||||
Each module is to contain a tests directory of the model being tested with a single file for grouping of what is being tested. for items that depend upon a parent model, the test file is to be within the child-models test directory named with format `test_<model>_<parent app>_<parent model name>`
|
||||
|
||||
_example file system structure for the device model that relies upon access app model organization, core app model history and model notes._
|
||||
|
||||
``` text
|
||||
|
||||
├── tests
|
||||
│ ├── <model name>
|
||||
│ │ ├── test_<model name>_access_organization.py
|
||||
│ │ ├── test_<model name>_api_permission.py
|
||||
│ │ ├── test_<model name>_core_history.py
|
||||
│ │ ├── test_<model name>_core_notes.py
|
||||
│ │ ├── test_<model name>_permission.py
|
||||
│ │ └── test_device.py
|
||||
|
||||
|
||||
```
|
||||
|
||||
Items to test include, and are not limited to:
|
||||
|
||||
- CRUD permissions admin site
|
||||
|
||||
- CRUD permissions api site
|
||||
|
||||
- CRUD permissions main site
|
||||
|
||||
- can only access organization object
|
||||
|
||||
- can access global object (still to require model CRUD permission)
|
||||
|
||||
- model
|
||||
|
||||
- history
|
||||
|
||||
- saves history with parent pk and parent class
|
||||
|
||||
add to model class the following
|
||||
|
||||
``` py
|
||||
|
||||
@property
|
||||
def parent_object(self):
|
||||
""" Fetch the parent object """
|
||||
|
||||
return self.<item that is the parent>
|
||||
|
||||
```
|
||||
|
||||
history should now be auto saved as long as class `core.mixin.history_save.SaveHistory` is inherited by model.
|
||||
|
||||
- history is deleted when item deleted if `parent_pk=None` or if has `parent_pk` deletes history on parent pk being deleted.
|
||||
|
||||
|
||||
## Running Tests
|
||||
|
||||
Test can be run by running the following:
|
||||
|
||||
1. `pip install -r requirements_test.txt -r requirements.txt`
|
||||
|
||||
1. `pytest --cov --cov-report html --cov=./`
|
||||
|
||||
If your developing using VSCode/VSCodium the testing is available as is the ability to attach a debugger to the test.
|
||||
|
||||
|
||||
## Test Cases
|
||||
|
||||
Models are tested using the following test cases:
|
||||
|
||||
- [ALL Model Permission](./model_permissions.md)
|
||||
@ -150,3 +45,5 @@ Models are tested using the following test cases:
|
||||
- [History Entry (Parent Item)](./model_history_parent_item.md)
|
||||
|
||||
- [History Entry Permissions](./model_history_permissions.md)
|
||||
|
||||
The above test cases are common to alot of models and function of this application and are intended to be inherited by your test class.
|
||||
|
||||
@ -1,17 +1,27 @@
|
||||
---
|
||||
title: Django Template Devlopment
|
||||
description: No Fuss Computings Django Site Template Development
|
||||
title: Django ITSM Development
|
||||
description: No Fuss Computings Django Site ITSM Development
|
||||
date: 2024-05-17
|
||||
template: project.html
|
||||
about: https://gitlab.com/nofusscomputing/infrastructure/configuration-management/django_app
|
||||
---
|
||||
|
||||
This page contains different items related to the development of this application.
|
||||
|
||||
Documentation for the application api is within it's own section, [API](./api/index.md).
|
||||
This section of the documentation different items related to the development of this application. The target audience is anyone whom wishes to develop any part of the application.
|
||||
|
||||
|
||||
## Icons
|
||||
## Handy links
|
||||
|
||||
- [Application API Documentation](./api/index.md)
|
||||
|
||||
- [Testing](./testing.mdd)
|
||||
|
||||
|
||||
## Random items to be relocated in the future
|
||||
|
||||
_the below sections need to be refactored._
|
||||
|
||||
|
||||
### Icons
|
||||
|
||||
To locate additional icons for use see [material icons](https://fonts.google.com/icons).
|
||||
|
||||
@ -26,7 +36,7 @@ Icons with text:
|
||||
- Issue `{% include 'icons/issue_link.html.j2' with issue=2 %}` _Used to provide a link to an issue on GitLab. i.e. incomplete feature ticket_
|
||||
|
||||
|
||||
## Adding an Application
|
||||
### Adding an Application
|
||||
|
||||
1. Install the django application with `pip <app-name>`
|
||||
|
||||
@ -62,12 +72,12 @@ Icons with text:
|
||||
Once you have completed the above list, your application will display collapsed within the navigation menu with the name of your application.
|
||||
|
||||
|
||||
## Tenancy Setup
|
||||
### Tenancy Setup
|
||||
|
||||
Within your view class include the mixin class `OrganizationPermission`, ensuring that you set the `permission_required` attribute.
|
||||
|
||||
|
||||
### Model Setup
|
||||
#### Model Setup
|
||||
|
||||
Any item you wish to be multi-tenant, ensure within your model you include the tenancy model abstract class. The class includes a field called `organization` which links directly to the organization model and is used by the tenancy permission check.
|
||||
|
||||
@ -81,7 +91,7 @@ class YourObject(TenancyObject):
|
||||
```
|
||||
|
||||
|
||||
### View Setup
|
||||
#### View Setup
|
||||
|
||||
The mixin inlcuded in this template `OrganizationPermission` is designed to work with all django built in views and is what does the multi-tenancy permission checks.
|
||||
|
||||
@ -117,7 +127,7 @@ class IndexView(OrganizationPermission, generic.ListView):
|
||||
Using a filter `pk__in=self.user_organizations()` for the queryset using the mixins function `user_organizations`, will limit the query set to only items where the user is a member of the organization.
|
||||
|
||||
|
||||
### Templates
|
||||
#### Templates
|
||||
|
||||
The base template includes blocks that are designed to assist in rendering your content. The following blocks are available:
|
||||
|
||||
@ -143,7 +153,7 @@ your content here
|
||||
```
|
||||
|
||||
|
||||
## Add history to model
|
||||
### Add history to model
|
||||
|
||||
The tracking of changes can be added to a model by including the `SaveHistory` mixin from `core.mixin.history_save` to the model.
|
||||
|
||||
|
||||
109
docs/projects/django-template/development/testing.md
Normal file
109
docs/projects/django-template/development/testing.md
Normal file
@ -0,0 +1,109 @@
|
||||
---
|
||||
title: Testing
|
||||
description: No Fuss Computings django itsm unit tests
|
||||
date: 2024-06-17
|
||||
template: project.html
|
||||
about: https://gitlab.com/nofusscomputing/infrastructure/configuration-management/django_app
|
||||
---
|
||||
|
||||
Unit tests are written to aid in application stability and to assist in preventing regression bugs. As part of development the developer working on a Merge/Pull request is to ensure that tests are written. Failing to do so will more likely than not ensure that your Merge/Pull request is not merged.
|
||||
|
||||
|
||||
## Writing Tests
|
||||
|
||||
We use class based tests. Each class will require a `setUpTestData` method for test setup. To furhter assist in the writing of tests, we have written the test cases for common items as an abstract class. You are advised to review the [test cases](./api/tests/index.md) and if it's applicable to the item you have added, than add the test case class to be inherited by your test class.
|
||||
|
||||
naming of test classes is in `CamelCase` in format `<Model Name><what's being tested>` for example the class name for device model history entry tests would be `DeviceHistory`.
|
||||
|
||||
Test setup is written in a method called `setUpTestData` and is to contain the setup for all tests within the test class.
|
||||
|
||||
Example of a model history test class.
|
||||
|
||||
``` py
|
||||
|
||||
import pytest
|
||||
import unittest
|
||||
import requests
|
||||
|
||||
from django.test import TestCase, Client
|
||||
|
||||
from core.models.history import History
|
||||
from core.tests.abstract.history_entry import HistoryEntry
|
||||
from core.tests.abstract.history_entry_parent_model import HistoryEntryParentItem
|
||||
|
||||
|
||||
|
||||
class DeviceHistory(TestCase, HistoryEntry, HistoryEntryParentItem):
|
||||
|
||||
|
||||
model = Device
|
||||
|
||||
|
||||
@classmethod
|
||||
def setUpTestData(self):
|
||||
""" Setup Test """
|
||||
|
||||
```
|
||||
|
||||
Each module is to contain a tests directory of the model being tested with a single file for grouping of what is being tested. for items that depend upon a parent model, the test file is to be within the child-models test directory named with format `test_<model>_<parent app>_<parent model name>`
|
||||
|
||||
_example file system structure for the device model that relies upon access app model organization, core app model history and model notes._
|
||||
|
||||
``` text
|
||||
|
||||
├── tests
|
||||
│ ├── <model name>
|
||||
│ │ ├── test_<model name>_access_organization.py
|
||||
│ │ ├── test_<model name>_api_permission.py
|
||||
│ │ ├── test_<model name>_core_history.py
|
||||
│ │ ├── test_<model name>_core_notes.py
|
||||
│ │ ├── test_<model name>_permission.py
|
||||
│ │ └── test_device.py
|
||||
|
||||
|
||||
```
|
||||
|
||||
Items to test include, and are not limited to:
|
||||
|
||||
- CRUD permissions admin site
|
||||
|
||||
- CRUD permissions api site
|
||||
|
||||
- CRUD permissions main site
|
||||
|
||||
- can only access organization object
|
||||
|
||||
- can access global object (still to require model CRUD permission)
|
||||
|
||||
- model
|
||||
|
||||
- history
|
||||
|
||||
- saves history with parent pk and parent class
|
||||
|
||||
add to model class the following
|
||||
|
||||
``` py
|
||||
|
||||
@property
|
||||
def parent_object(self):
|
||||
""" Fetch the parent object """
|
||||
|
||||
return self.<item that is the parent>
|
||||
|
||||
```
|
||||
|
||||
history should now be auto saved as long as class `core.mixin.history_save.SaveHistory` is inherited by model.
|
||||
|
||||
- history is deleted when item deleted if `parent_pk=None` or if has `parent_pk` deletes history on parent pk being deleted.
|
||||
|
||||
|
||||
## Running Tests
|
||||
|
||||
Test can be run by running the following:
|
||||
|
||||
1. `pip install -r requirements_test.txt -r requirements.txt`
|
||||
|
||||
1. `pytest --cov --cov-report html --cov=./`
|
||||
|
||||
If your developing using VSCode/VSCodium the testing is available as is the ability to attach a debugger to the test.
|
||||
Reference in New Issue
Block a user