genlayer-test 0.8.0__tar.gz → 0.10.0__tar.gz

{genlayer_test-0.8.0 → genlayer_test-0.10.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: genlayer-test
-Version: 0.8.0
+Version: 0.10.0
 Summary: GenLayer Testing Suite
 Author: GenLayer
 License-Expression: MIT
@@ -140,6 +140,7 @@ networks:
   custom_network:  # Custom network configuration
     id: 1234
     url: "http://custom.network:8545"
+    chain_type: "localnet"  # Required for custom networks: localnet, studionet, or testnet_asimov
     accounts:
       - "${CUSTOM_ACCOUNT_1}"
       - "${CUSTOM_ACCOUNT_2}"
@@ -163,10 +164,11 @@ Key configuration sections:
    - Network configurations can include:
      - `url`: The RPC endpoint for the network (optional for pre-configured networks)
      - `id`: Chain ID (optional for pre-configured networks)
+     - `chain_type`: Chain type - one of: `localnet`, `studionet`, or `testnet_asimov` (required for custom networks)
      - `accounts`: List of account private keys (using environment variables)
      - `from`: Specify which account to use as the default for transactions (optional, defaults to first account)
      - `leader_only`: Leader only mode
-   - For custom networks (non-pre-configured), `id`, `url`, and `accounts` are required fields
+   - For custom networks (non-pre-configured), `id`, `url`, `chain_type`, and `accounts` are required fields
 
 **Note on Environment Variables**: When using environment variables in your configuration (e.g., `${ACCOUNT_PRIVATE_KEY_1}`), ensure they are properly set in your `environment` file. If an environment variable is not found, the system will raise a clear error message indicating which variable is missing.
 
@@ -182,6 +184,13 @@ testnet_asimov:
   from: "${ADMIN_KEY}"       # Use ADMIN_KEY as default instead of DEPLOYER_KEY
 ```
 
+**Chain vs Network**: 
+- **Network**: Defines the connection details (URL, accounts, etc.) for a specific environment
+- **Chain**: Defines the genlayer chain type and its associated behaviors (localnet, studionet, or testnet_asimov)
+- Pre-configured networks automatically have the correct chain type set
+- Custom networks must specify the chain type explicitly
+- The `--chain-type` CLI flag can override the chain type for any network, allowing you to test different chain behaviors with the same network configuration
+
 2. **Paths**: Define important directory paths
    - `contracts`: Location of your contract files
    - `artifacts`: Location of your artifacts files (analysis results will be stored here)
@@ -261,31 +270,7 @@ $ gltest --default-wait-interval <default_wait_interval>
 $ gltest --default-wait-retries <default_wait_retries>
 ```
 
-10. Run tests with mocked LLM responses (localnet only)
-```bash
-$ gltest --test-with-mocks
-```
-The `--test-with-mocks` flag enables mocking of LLM responses when creating validators. This is particularly useful for:
-- Testing without actual LLM API calls
-- Ensuring deterministic test results
-- Faster test execution
-- Testing specific edge cases with controlled responses
-
-When using this flag with the `setup_validators` fixture, you can provide custom mock responses:
-```python
-def test_with_mocked_llm(setup_validators):
-    # Setup validators with a specific mock response
-    mock_response = {"result": "This is a mocked LLM response"}
-    setup_validators(mock_response=mock_response)
-    
-    # Your LLM-based contract will receive the mocked response
-    contract = factory.deploy()
-    result = contract.llm_method()  # Will use the mocked response
-```
-
-Note: This feature is only available when running tests on localnet.
-
-11. Run tests with leader-only mode enabled
+10. Run tests with leader-only mode enabled
 ```bash
 $ gltest --leader-only
 ```
@@ -299,6 +284,24 @@ When this flag is enabled, all contracts deployed and all write transactions wil
 
 **Note:** Leader-only mode is only available for studio-based networks (localhost, 127.0.0.1, *.genlayer.com, *.genlayerlabs.com). When enabled on other networks, it will have no effect and a warning will be logged.
 
+12. Override the chain type
+```bash
+$ gltest --chain-type localnet
+$ gltest --chain-type studionet
+$ gltest --chain-type testnet_asimov
+```
+The `--chain-type` flag allows you to override the chain type configured for the network. This is useful when:
+- Testing different chain behaviors without changing network configuration
+- Switching between chain types for testing purposes
+- Using a custom network URL with a specific chain type
+
+Available chain types:
+- `localnet`: Local development chain
+- `studionet`: Studio-based chain
+- `testnet_asimov`: Testnet Asimov chain
+
+The chain type determines various behaviors including RPC endpoints, consensus mechanisms, and available features. When specified, this flag overrides the chain type configured in your network settings.
+
 ## 🚀 Key Features
 
 - **Pytest Integration** – Extends pytest to support intelligent contract testing, making it familiar and easy to adopt.
@@ -448,7 +451,7 @@ def test_write_methods():
     ).transact(
         value=0,  # Optional: amount of native currency to send
         consensus_max_rotations=3,  # Optional: max consensus rotations
-        wait_interval=1,  # Optional: seconds between status checks
+        wait_interval=1000,  # Optional: milliseconds between status checks
         wait_retries=10,  # Optional: max number of retries
         transaction_context=None,  # Optional: custom transaction context
     )
@@ -511,7 +514,6 @@ The following fixtures are available in `gltest.fixtures`:
 - **`gl_client`** (session scope) - GenLayer client instance for network operations
 - **`default_account`** (session scope) - Default account for testing and deployments
 - **`accounts`** (session scope) - List of test accounts for multi-account scenarios
-- **`setup_validators`** (function scope) - Function to create test validators for LLM operations
 
 ##### 1. `gl_client` (session scope)
 Provides a GenLayer PY client instance that's created once per test session. This is useful for operations that interact directly with the GenLayer network.
@@ -546,26 +548,6 @@ def test_multiple_accounts(accounts):
     contract.transfer(args=[receiver.address, 100], account=sender)
 ```
 
-##### 4. `setup_validators` (function scope)
-Creates test validators for localnet environment. This fixture is particularly useful for testing LLM-based contract methods and consensus behavior. It yields a function that allows you to configure validators with custom settings.
-
-```python
-def test_with_validators(setup_validators):
-    # Setup validators with default configuration
-    setup_validators()
-    
-    # Or setup with custom mock responses for testing
-    mock_response = {"result": "mocked LLM response"}
-    setup_validators(mock_response=mock_response, n_validators=3)
-    
-    # Now test your LLM-based contract methods
-    contract = factory.deploy()
-    result = contract.llm_based_method()
-```
-
-Parameters for `setup_validators`:
-- `mock_response` (dict, optional): Mock validator response when using `--test-with-mocks` flag
-- `n_validators` (int, optional): Number of validators to create (default: 5)
 
 #### Using Fixtures in Your Tests
 
@@ -575,9 +557,7 @@ To use these fixtures, simply import them and include them as parameters in your
 from gltest import get_contract_factory
 from gltest.assertions import tx_execution_succeeded
 
-def test_complete_workflow(gl_client, default_account, accounts, setup_validators):
-    # Setup validators for LLM operations
-    setup_validators()
+def test_complete_workflow(gl_client, default_account, accounts):
     
     # Deploy contract with default account
     factory = get_contract_factory("MyContract")
@@ -623,7 +603,7 @@ def test_analyze_method():
     print(f"Reliability score: {analysis.reliability_score:.2f}%")
     print(f"Unique states: {analysis.unique_states}")
     print(f"Execution time: {analysis.execution_time:.1f}s")
-    
+
     # The analysis returns a MethodStatsSummary object with:
     # - method: The contract method name
     # - args: Arguments passed to the method
@@ -641,127 +621,6 @@ The `.analyze()` method helps you:
 - Identify edge cases and failure patterns
 - Benchmark performance across multiple runs
 
-### Mock LLM Responses
-
-The Mock LLM system allows you to simulate Large Language Model responses in GenLayer tests. This is essential for creating deterministic tests by providing predefined responses instead of relying on actual LLM calls.
-
-#### Basic Structure
-
-The mock system consists of a response dictionary that maps GenLayer methods to their mocked responses:
-
-```python
-mock_response = {
-    "response": {},                               # Optional: mocks gl.nondet.exec_prompt
-    "eq_principle_prompt_comparative": {},        # Optional: mocks gl.eq_principle.prompt_comparative
-    "eq_principle_prompt_non_comparative": {}     # Optional: mocks gl.eq_principle.prompt_non_comparative
-}
-
-setup_validators(mock_response)
-```
-
-#### Method Mappings
-
-| Mock Key | GenLayer Method |
-|----------|----------------|
-| `"response"` | `gl.nondet.exec_prompt` |
-| `"eq_principle_prompt_comparative"` | `gl.eq_principle.prompt_comparative` |
-| `"eq_principle_prompt_non_comparative"` | `gl.eq_principle.prompt_non_comparative` |
-
-#### How It Works
-
-The mock system works by pattern matching against the user message that gets built internally. When a GenLayer method is called:
-
-1. A user message is constructed internally (`<user_message>`)
-2. The mock system searches for strings within that message
-3. If a matching string is found in the mock dictionary, the associated response is returned
-
-##### String Matching Rules
-
-The system performs **substring matching** on the user message. The key in your mock dictionary must be contained within the actual user message.
-
-#### Examples
-
-##### Basic Example
-
-```python
-# Mock setup
-mock_response = {
-    "eq_principle_prompt_comparative": {
-        "The value of give_coin has to match": True
-    }
-}
-setup_validators(mock_response)
-
-# In your contract
-result = gl.eq_principle.prompt_comparative(
-    get_wizard_answer, 
-    "The value of give_coin has to match"  # This string will be matched
-)
-# result will be True
-```
-
-##### Substring Matching Examples
-
-✅ **Will work** - Partial match:
-```python
-"eq_principle_prompt_comparative": {
-    "The value of give_coin": True  # Substring of the full message
-}
-```
-
-❌ **Won't work** - Extra words break the match:
-```python
-"eq_principle_prompt_comparative": {
-    "The good value of give_coin": True  # "good" is not in the actual message
-}
-```
-
-##### Complete Example
-
-```python
-from gltest import get_contract_factory
-from gltest.fixtures import setup_validators
-
-def test_with_mocked_llm(setup_validators):
-    # Define mock responses
-    mock_response = {
-        "response": {
-            "What is the weather?": "It's sunny today",
-            "Calculate 2+2": "4"
-        },
-        "eq_principle_prompt_comparative": {
-            "values must be equal": True,
-            "amounts should match": False
-        },
-        "eq_principle_prompt_non_comparative": {
-            "Is this valid?": True
-        }
-    }
-    
-    # Initialize the mock system
-    setup_validators(mock_response)
-    
-    # Deploy and test your contract
-    factory = get_contract_factory("MyLLMContract")
-    contract = factory.deploy()
-    
-    # Your LLM methods will use the mocked responses
-    result = contract.check_weather()  # Uses mocked response
-```
-
-#### Best Practices
-
-1. **Be specific with match strings**: Use unique substrings that won't accidentally match other prompts
-2. **Test your matches**: Verify that your mock strings actually appear in the generated user messages
-3. **Keep mocks simple**: Mock responses should be minimal and focused on the test case
-4. **Document your mocks**: Comment why specific responses are mocked for future reference
-5. **Use with `--test-with-mocks` flag**: Enable mocking when running tests: `gltest --test-with-mocks`
-
-#### Notes
-
-- Mock responses are only available when running tests on localnet
-- The `setup_validators` fixture handles the mock setup when provided with a mock_response
-- Mocking is particularly useful for CI/CD pipelines where deterministic results are required
 
 ### Custom Transaction Context
 
@@ -812,17 +671,58 @@ def test_with_custom_transaction_context():
     )
 ```
 
+### Mock LLM Responses
+
+The Mock LLM system allows you to simulate Large Language Model responses in GenLayer tests. This is essential for creating deterministic tests by providing predefined responses instead of relying on actual LLM calls.
+
+#### Basic Structure
+
+The mock system consists of a response dictionary that maps GenLayer methods to their mocked responses:
+
+```python
+from gltest.types import MockedLLMResponse
+
+mock_response: MockedLLMResponse = {
+    "nondet_exec_prompt": {},                               # Optional: mocks gl.nondet.exec_prompt
+    "eq_principle_prompt_comparative": {},        # Optional: mocks gl.eq_principle.prompt_comparative
+    "eq_principle_prompt_non_comparative": {}     # Optional: mocks gl.eq_principle.prompt_non_comparative
+}
+```
+
+#### Method Mappings
+
+| Mock Key | GenLayer Method |
+|----------|----------------|
+| `"nondet_exec_prompt"` | `gl.nondet.exec_prompt` |
+| `"eq_principle_prompt_comparative"` | `gl.eq_principle.prompt_comparative` |
+| `"eq_principle_prompt_non_comparative"` | `gl.eq_principle.prompt_non_comparative` |
+
+#### How It Works
+
+The mock system works by pattern matching against the user message that gets built internally. When a GenLayer method is called:
+
+1. A user message is constructed internally (`<user_message>`)
+2. The mock system searches for strings within that message
+3. If a matching string is found in the mock dictionary, the associated response is returned
+
+##### String Matching Rules
+
+The system performs **substring matching** on the user message. The key in your mock dictionary must be contained within the actual user message.
+
+
 #### Mock Validators with Transaction Context
 
 Combine mock validators with custom datetime for fully deterministic tests:
 
 ```python
+from gltest.types import MockedLLMResponse
+
 def test_with_mocked_context():
     factory = get_contract_factory("LLMContract")
     validator_factory = get_validator_factory()
     
     # Define mock LLM responses
-    mock_response = {
+    mock_response: MockedLLMResponse = {
         "nondet_exec_prompt": {
             "analyze this": "positive sentiment"
         },
@@ -1014,7 +914,7 @@ def test_validator_cloning():
    tx_receipt = contract.set_value(
        args=["new_value"],
    ).transact(
-       wait_interval=2,  # Increase wait interval between status checks
+       wait_interval=2000,  # Increase wait interval between status checks
        wait_retries=20,  # Increase number of retry attempts
    )
    ```
@@ -1031,7 +931,7 @@ def test_validator_cloning():
    # For critical operations, use more conservative settings
    contract = factory.deploy(
        consensus_max_rotations=10,  # More rotations for better reliability
-       wait_interval=3,  # Longer wait between checks
+       wait_interval=3000,  # Longer wait between checks
        wait_retries=30  # More retries for consensus
    )
    ```