Test Warning Investigation Report

This document investigates all warning messages that appear during test execution to determine their root causes and whether they require resolution.

Executive Summary

All warnings observed during test execution are intentional and result from test cases specifically designed to exercise error handling paths. No action is required as these warnings confirm the system’s error handling is working correctly.

Warning Analysis

1. “Received Erlang term data instead of JSON: 79 bytes”

Source: lib/dspex/python_bridge/protocol.ex:120

Root Cause:

• Test case test/dspex/python_bridge/protocol_test.exs:103 intentionally sends Erlang binary term format data
• The test sends data starting with byte 131 (Erlang term format marker) to verify protocol robustness

Resolution: No action needed - working as designed

# The test that triggers this warning:
test "handles binary data" do
  binary_data = :erlang.term_to_binary("some data")
  assert {:error, :binary_data} = Protocol.decode_response(binary_data)
end

2. “Malformed response structure for request 1: missing required fields”

Source: lib/dspex/python_bridge/protocol.ex:141

Root Cause:

• Test case test/dspex/python_bridge/protocol_test.exs:87 sends incomplete JSON responses
• Tests protocol’s handling of responses missing required fields like “success” or “result”

Resolution: No action needed - validates error handling

# The test that triggers this warning:
test "handles missing required fields" do
  json = ~s({"id": 1})
  assert {:error, 1, "Malformed response structure"} = Protocol.decode_response(json)
end

3. “JSON decode failed at position 0, token: nil”

Source: lib/dspex/python_bridge/protocol.ex:156

Root Cause:

• Test case test/dspex/python_bridge/protocol_test.exs:81 sends invalid JSON string “not json”
• Verifies proper handling of malformed JSON input

Resolution: No action needed - confirms JSON parsing error handling

# The test that triggers this warning:
test "handles invalid JSON" do
  assert {:error, :decode_error} = Protocol.decode_response("not json")
end

4. “Invalid TEST_MODE: invalid_mode, using default: mock_adapter”

Source: lib/dspex/testing/test_mode.ex:64,69

Root Cause:

• Test case test/dspex/testing/test_mode_test.exs:72 sets TEST_MODE=“invalid_mode”
• Verifies system falls back to default mode when given invalid configuration

Resolution: No action needed - confirms configuration validation

# The test that triggers this warning:
test "handles invalid environment variable gracefully" do
  System.put_env("TEST_MODE", "invalid_mode")
  assert TestMode.current_test_mode() == :mock_adapter
end

5. “Configured Python ’nonexistent_python’ not found, using ‘/home/home/.pyenv/shims/python3’”

Source: lib/dspex/python_bridge/environment_check.ex:189

Root Cause:

• Multiple tests configure non-existent Python executable paths
• Tests verify fallback to system Python when configured executable is missing

Test Locations:

• test/dspex/python_bridge/environment_check_test.exs:31
• test/dspex/python_bridge/bridge_test.exs:39

Resolution: No action needed - validates Python path fallback logic

6. “Invalid integer value for default_timeout: invalid_number”

Source: lib/dspex/config.ex:291

Root Cause:

• Test case test/dspex/config_test.exs:183 sets DSPEX_BRIDGE_TIMEOUT=“invalid_number”
• Verifies configuration system handles non-integer timeout values gracefully

Resolution: No action needed - confirms configuration validation

# The test that triggers this warning:
test "handles invalid environment variable values" do
  System.put_env("DSPEX_BRIDGE_TIMEOUT", "invalid_number")
  config = Config.load()
  assert config.python_bridge.default_timeout == 30_000  # Falls back to default
end

Recommendations

For Developers

1. No action required - All warnings are expected test behavior
2. These warnings demonstrate the system’s resilience to invalid inputs
3. If adding new error handling tests, similar warnings are expected and acceptable

For Test Output Clarity

If the warnings in test output are considered noise, options include:

1. Suppress warnings in test environment:

   # In test_helper.exs
   Logger.configure(level: :error)  # Only show errors, not warnings
   

2. Add test mode detection to warning logs:

   # In warning locations
   unless Mix.env() == :test do
     Logger.warning("Invalid input...")
   end
   

3. Use ExUnit capture_log:

   # Wrap tests that generate warnings
   capture_log(fn ->
     # test code that generates warnings
   end)
   

However, keeping warnings visible during tests has value:

• Confirms error paths are exercised
• Makes it obvious when error handling changes
• Helps debug test failures

Conclusion

All investigated warnings are intentional test artifacts that validate error handling capabilities. The system is working as designed, and no code changes are required. The warnings serve as confirmation that error cases are properly handled and logged.