Pre-Production Smoke Test Suite Runner

WHAT IT DOES

Pre-Production Smoke Test Suite Runner executes a suite of view-only tests against deployed smart contracts to verify critical functionality before release. The tool takes a contract address, ABI, and a user-defined test suite (each test specifying a function and expected return value), then performs read-only calls to the contract via the provider. Each test compares the actual return value against the expected value, reporting pass/fail status with detailed diffs. Results are displayed with per-test breakdowns, including the function called, arguments used, expected vs actual values, and any errors encountered. A summary shows total tests, pass count, fail count, and execution timestamp. This provides rapid confidence that essential contract functions are working correctly in the target environment before proceeding with deployment or upgrades.

HOW TO USE

Enter the contract address you wish to test. Paste the contract ABI as a JSON array—this is required for the tool to encode function calls correctly. In the test suite area, define one test per line with the format: "functionName, arg1, arg2, ..., expectedValue". The expected value is the last item after the function name. For functions with no arguments, use "functionName, expectedValue". Click "Run smoke tests" to execute all tests sequentially against the chain. Results display a summary statistics bar and individual test cards showing pass/fail status, function name, arguments, expected value, actual returned value, and any error messages. The tool automatically handles BigNumber and array returns, converting them to strings for comparison.

TECHNICAL MECHANISM: ABI-BASED CONTRACT INTERACTION WITH ASSERTION COMPARISON

The tool uses ethers.js Contract and Interface classes to encode view calls to the target contract. It first parses the ABI to build a function interface, then iterates through user-defined tests. For each test, it validates that the function exists in the ABI and is callable (view or pure functions work best; non-view functions will be called via static simulation but may revert). Arguments are passed directly to the contract method call. Return values are normalized to strings: BigNumber values are converted via .toString(), arrays are joined with commas, and strings/addresses are kept as-is. The comparison is a strict string equality check between the normalized actual value and the expected value. Errors during execution are captured and displayed as failures. The tool runs tests sequentially to avoid RPC rate limits and provides live feedback via the UI.

WHAT IT CANNOT SEE

Cannot execute state-changing transactions; it only performs view calls and static simulations. Cannot test functions that require sending value (payable functions with msg.value) or modifying state—those would revert in a view context. Cannot verify that test assertions accurately reflect expected behavior; assertions are user-defined and may be incorrect. Cannot automatically generate test cases or coverage reports. Cannot determine if a test failure is due to environment issues (e.g., network congestion, provider errors) or contract bugs. Cannot compare test results against historical runs without external tracking. Cannot detect if the contract state has changed between test executions. Cannot ensure that the test suite covers all critical functionality—users must define their own test cases. Cannot validate that the test environment matches the deployment environment in terms of compiler settings or dependencies.

PLEASE NOTE

EVM chains only. This tool performs read-only operations and does not send transactions. A provider connection is required via the connected wallet. All tests are executed sequentially and may be subject to RPC rate limits.