Because of large common prefix hash naming becomes "too sequential" when doing a lot of concurrent writes. I don't know a good tradeoff between both use cases: 1. Lots of reads - prefers large shared prefix. 2. Lots of writes - prefers small shared prefix. But as of now this punishes writes too badly in form of excessive locking. Until a better fix is found, it's better to keep it prefix free. --- A better fix would be a tradeoff of between these two: 1. Reads - temporal locality should result in spatial locality on disk. 2. Writes - temporal locality should NOT result in spatial locality. temporal locality = data inserted around same time spatial locality = data sits next to each other in DB pages. This can be achieved by adding a small request/job specific part to prefix so each concurrent request has it's own different locality when writing data. |
||
|---|---|---|
| .. | ||
| classes | ||
| data | ||
| utils | ||
| __init__.py | ||
| README.md | ||
| test_api.py | ||
| test_api_v2.py | ||
| test_assign.py | ||
| test_auth.py | ||
| test_background_jobs.py | ||
| test_base_document.py | ||
| test_boilerplate.py | ||
| test_boot.py | ||
| test_caching.py | ||
| test_child_table.py | ||
| test_client.py | ||
| test_commands.py | ||
| test_config.py | ||
| test_cors.py | ||
| test_dashboard_connections.py | ||
| test_db.py | ||
| test_db_query.py | ||
| test_db_update.py | ||
| test_defaults.py | ||
| test_deferred_insert.py | ||
| test_doc_ref.py | ||
| test_docstatus.py | ||
| test_document.py | ||
| test_document_locks.py | ||
| test_document_ro_mode.py | ||
| test_domainification.py | ||
| test_dynamic_links.py | ||
| test_email.py | ||
| test_exporter_fixtures.py | ||
| test_fixture_import.py | ||
| test_fmt_datetime.py | ||
| test_fmt_money.py | ||
| test_form_load.py | ||
| test_formatter.py | ||
| test_frappe_client.py | ||
| test_geo_ip.py | ||
| test_global_search.py | ||
| test_goal.py | ||
| test_hooks.py | ||
| test_linked_with.py | ||
| test_listview.py | ||
| test_model_utils.py | ||
| test_modules.py | ||
| test_monitor.py | ||
| test_naming.py | ||
| test_nestedset.py | ||
| test_non_nullable_docfield.py | ||
| test_oauth20.py | ||
| test_password.py | ||
| test_password_strength.py | ||
| test_patches.py | ||
| test_pdf.py | ||
| test_perf.py | ||
| test_permissions.py | ||
| test_printview.py | ||
| test_query.py | ||
| test_query_builder.py | ||
| test_query_report.py | ||
| test_rate_limiter.py | ||
| test_rating.py | ||
| test_recorder.py | ||
| test_redis.py | ||
| test_rename_doc.py | ||
| test_reportview.py | ||
| test_safe_exec.py | ||
| test_scheduler.py | ||
| test_search.py | ||
| test_seen.py | ||
| test_sequence.py | ||
| test_sitemap.py | ||
| test_test_utils.py | ||
| test_trace.py | ||
| test_translate.py | ||
| test_twofactor.py | ||
| test_utils.py | ||
| test_virtual_doctype.py | ||
| test_webform.py | ||
| test_website.py | ||
| tests_geo_utils.py | ||
| translation_test_file.txt | ||
| ui_test_helpers.py | ||
Frappe Test Framework
This README provides an overview of the test case framework available in Frappe. These utilities are designed to facilitate efficient and effective testing of Frappe applications.
This is different from the frappe.testing module which houses the discovery and runner infrastructure for CLI and CI.
Directory Structure
The test framework is organized into the following structure:
frappe/tests/
├── classes/
│ ├── context_managers.py
│ ├── unit_test_case.py
│ └── ...
├── utils/
│ ├── generators.py
│ └── ...
├── test_api.py
├── test_child_table.py
└── ...
Key Components
- Test case classes (UnitTestCase and IntegrationTestCase)
- Framework and class specific context managers
- Utility functions and generators
- Specific test modules for various Frappe components
Test Case Classes
UnitTestCase (classes/unit_test_case.py)
Import convention: from frappe.tests import UnitTestCase
This class extends unittest.TestCase and provides additional utilities specific to the Frappe framework. It's designed for testing individual components or functions in isolation.
Key features include:
- Custom assertions for Frappe-specific comparisons
- Utilities for HTML and SQL normalization
- Context managers for user switching and time freezing
IntegrationTestCase (classes/integration_test_case.py)
Import convention: from frappe.tests import IntegrationTestCase
This class extends UnitTestCase and is designed for integration testing. It provides features for:
- Automatic site and connection setup
- Automatic test records loading
- Automatic reset of thread locals
- Context managers that depend on a site connection
- Asserts that depend on a site connection
For a detailed list of context managers, please refer to the code.
Utility Functions and Generators (utils/generators.py)
This module contains utility functions for generating test records and managing test data.
Specific Test Modules
Various test modules (e.g., test_api.py, test_document.py) contain tests for specific Frappe core components and functionalities.
Note that Document tests are collocated alongside each Document module.
Usage
To use these test utilities in your Frappe application tests, you can inherit from the appropriate test case class:
from frappe.tests import UnitTestCase
class MyTestCase(UnitTestCase):
def test_something(self):
# Your test code here
pass
Contributing
When adding new test utilities or modifying existing ones:
- Place them in the appropriate directory based on their function.
- Update this README to reflect any significant changes in the framework structure or usage.
- Ensure that your changes follow the existing coding style and conventions.
Remember to always refer to the actual code for the most up-to-date and detailed information on available methods and their usage.