mirror of
				https://github.com/HackSoftware/Django-Styleguide.git
				synced 2025-10-31 15:47:25 +03:00 
			
		
		
		
	Add initial testing section with naming convetion
This commit is contained in:
		
							parent
							
								
									83cdd847ec
								
							
						
					
					
						commit
						60b649fc31
					
				
							
								
								
									
										62
									
								
								README.md
									
									
									
									
									
								
							
							
						
						
									
										62
									
								
								README.md
									
									
									
									
									
								
							|  | @ -562,6 +562,68 @@ class CourseCreateApi( | |||
| 
 | ||||
| All of code above can be found in `utils.py` in this repository. | ||||
| 
 | ||||
| ## Testing | ||||
| 
 | ||||
| In our Django projects, we split our tests depending on the type of code they represent. | ||||
| 
 | ||||
| Meaning, we generally have tests for models, services, selectors & APIs / views. | ||||
| 
 | ||||
| The file structure usually looks like this: | ||||
| 
 | ||||
| ``` | ||||
| project_name | ||||
| ├── app_name | ||||
| │   ├── __init__.py | ||||
| │   └── tests | ||||
| │       ├── __init__.py | ||||
| │       ├── models | ||||
| │       │   └── test_some_model_name.py | ||||
| │       ├── selectors | ||||
| │       │   └── test_some_selector_name.pyy | ||||
| │       └── services | ||||
| │           ├── __init__.py | ||||
| │           └── test_some_service_name.py | ||||
| └── __init__.py | ||||
| ``` | ||||
| 
 | ||||
| ### Naming conventions | ||||
| 
 | ||||
| We follow 2 general naming conventions: | ||||
| 
 | ||||
| * The test file names should be `test_the_name_of_the_thing_that_is_tested.py` | ||||
| * The test case shoud be `class TheNameOfTheThingThatIsTestedTests(TestCase):` | ||||
| 
 | ||||
| For example if we have: | ||||
| 
 | ||||
| ```python | ||||
| def a_very_neat_service(*args, **kwargs): | ||||
|     pass | ||||
| ``` | ||||
| 
 | ||||
| We are going to have the following for file name: | ||||
| 
 | ||||
| ``` | ||||
| project_name/app_name/tests/services/test_a_very_neat_service.py | ||||
| ``` | ||||
| 
 | ||||
| And the following for test case: | ||||
| 
 | ||||
| ```python | ||||
| class AVeryNeatServiceTests(TestCase): | ||||
|     pass | ||||
| ``` | ||||
| 
 | ||||
| For tests of utility functions, we follow a similiar pattern. | ||||
| 
 | ||||
| For example, if we have `project_name/common/utils.py`, then we are going to have `project_name/common/tests/test_utils.py` and place different test cases in that file. | ||||
| 
 | ||||
| If we are to split the `utils.py` module into submodules, the same will happen for the tests: | ||||
| 
 | ||||
| * `project_name/common/utils/files.py` | ||||
| * `project_name/common/tests/utils/test_files.py` | ||||
| 
 | ||||
| We try to match the stucture of our modules with the structure of their respective tests. | ||||
| 
 | ||||
| ## Inspiration | ||||
| 
 | ||||
| The way we do Django is inspired by the following things: | ||||
|  |  | |||
		Loading…
	
		Reference in New Issue
	
	Block a user