Testing Solidity Constructor Behavior with Deployment Assertions

Why constructor testing matters

In Solidity, the constructor is where you establish the contract’s initial trust boundary. Common examples include:

• setting the owner or admin
• storing immutable configuration
• validating constructor arguments
• seeding token supply or initial balances
• wiring external dependencies such as oracle addresses or routers

A constructor failure is not just a runtime error. It can create a contract that is deployed successfully but initialized incorrectly, which is often worse because the mistake may not be obvious until funds are at risk.

Constructor testing is especially useful when:

• deployment parameters come from scripts or environment variables
• the constructor performs multiple validations
• the contract uses immutable variables
• the contract inherits from multiple base contracts
• initialization must match off-chain assumptions

What to test in a constructor

A good constructor test suite focuses on observable deployment outcomes.

The key idea is simple: if the constructor sets it, your tests should prove it.

A practical example: an initialized vault

Consider a minimal vault contract that accepts an owner, an asset address, and a deposit cap during deployment.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract Vault {
    address public immutable owner;
    address public immutable asset;
    uint256 public immutable cap;
    bool public paused;

    error ZeroAddress();
    error InvalidCap();

    constructor(address _owner, address _asset, uint256 _cap) {
        if (_owner == address(0) || _asset == address(0)) revert ZeroAddress();
        if (_cap == 0) revert InvalidCap();

        owner = _owner;
        asset = _asset;
        cap = _cap;
        paused = true;
    }
}

This contract has a few important deployment-time guarantees:

• owner and asset cannot be zero addresses
• cap must be nonzero
• the vault starts paused
• the values are stored immutably

A constructor test should verify all of those behaviors.

Testing deployment assertions with Foundry

Foundry is well suited for constructor testing because deployment is explicit and assertions are concise. A typical pattern is to deploy the contract inside a test and immediately inspect its state.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "forge-std/Test.sol";
import "../src/Vault.sol";

contract VaultTest is Test {
    function testConstructorSetsInitialState() public {
        address owner = address(0x1234);
        address asset = address(0x5678);
        uint256 cap = 1_000 ether;

        Vault vault = new Vault(owner, asset, cap);

        assertEq(vault.owner(), owner);
        assertEq(vault.asset(), asset);
        assertEq(vault.cap(), cap);
        assertTrue(vault.paused());
    }

    function testConstructorRejectsZeroOwner() public {
        vm.expectRevert(Vault.ZeroAddress.selector);
        new Vault(address(0), address(0x5678), 1_000 ether);
    }

    function testConstructorRejectsZeroAsset() public {
        vm.expectRevert(Vault.ZeroAddress.selector);
        new Vault(address(0x1234), address(0), 1_000 ether);
    }

    function testConstructorRejectsZeroCap() public {
        vm.expectRevert(Vault.InvalidCap.selector);
        new Vault(address(0x1234), address(0x5678), 0);
    }
}

Why this style works

This pattern is effective because it tests the constructor the same way production deploys it: by creating a new instance. There is no need for special harness logic unless the constructor depends on complex inheritance or external calls.

A few best practices:

• use explicit addresses in tests instead of msg.sender when the constructor accepts parameters
• check every stored value that should be initialized
• test each revert branch independently
• prefer custom error selectors over string matching when possible

Verifying deployment context and msg.sender

Many constructors derive ownership from the deployer rather than from a constructor argument. In that case, the test should assert the deployment context directly.

contract OwnableVault {
    address public owner;

    constructor() {
        owner = msg.sender;
    }
}

A test can deploy from the default test contract or use vm.prank to control the deployer.

function testOwnerDefaultsToDeployer() public {
    OwnableVault vault = new OwnableVault();
    assertEq(vault.owner(), address(this));
}

function testOwnerCanBeSetByDifferentDeployer() public {
    address deployer = address(0xBEEF);
    vm.prank(deployer);
    OwnableVault vault = new OwnableVault();

    assertEq(vault.owner(), deployer);
}

This is important when deployment scripts use a dedicated deployer account. If the constructor assumes the wrong sender, ownership may be assigned to the script contract instead of the intended admin.

Testing inherited constructors

Inheritance adds another layer of risk because the base constructor may enforce its own rules. A derived contract should be tested for both local and inherited initialization.

contract BaseConfig {
    uint256 public immutable chainId;

    constructor(uint256 _chainId) {
        chainId = _chainId;
    }
}

contract DerivedVault is BaseConfig {
    address public immutable treasury;

    constructor(uint256 _chainId, address _treasury) BaseConfig(_chainId) {
        treasury = _treasury;
    }
}

Test both values after deployment:

function testInheritedConstructorState() public {
    DerivedVault vault = new DerivedVault(1, address(0xCAFE));

    assertEq(vault.chainId(), 1);
    assertEq(vault.treasury(), address(0xCAFE));
}

If the base constructor includes validation, add revert tests for those conditions too. Constructor tests should cover the full inheritance chain, not only the derived contract’s own fields.

Testing computed initialization

Constructors often compute derived values rather than storing arguments directly. For example, a fee contract may calculate a scaled rate or a deadline window.

contract FeeConfig {
    uint256 public immutable feeBps;
    uint256 public immutable maxFee;

    constructor(uint256 _feeBps, uint256 _baseAmount) {
        require(_feeBps <= 1_000, "fee too high");
        feeBps = _feeBps;
        maxFee = (_baseAmount * _feeBps) / 10_000;
    }
}

In this case, the test should verify the formula, not just the raw inputs.

function testComputedInitialization() public {
    FeeConfig config = new FeeConfig(250, 1_000_000);

    assertEq(config.feeBps(), 250);
    assertEq(config.maxFee(), 25_000);
}

When testing computed state, pay attention to rounding. Solidity integer division truncates toward zero, so tests should use exact expected values and include edge cases where truncation matters.

Constructor testing best practices

A strong constructor test suite is small but precise. Use the following guidelines to keep it maintainable.

1. Test the deployment contract, not just the source code

If a deployment script passes constructor arguments, test the same argument shape in your suite. This catches mismatches between scripts and contracts.

2. Assert every meaningful state variable

If the constructor sets a variable that affects permissions, accounting, or external integration, assert it. Do not assume a single “happy path” check is enough.

3. Separate success and failure cases

A successful deployment test should not also try to prove reverts. Keep positive and negative tests isolated so failures are easier to diagnose.

4. Prefer custom errors for constructor validation

Custom errors are cheaper and easier to assert precisely. They also make constructor failures more explicit than generic revert strings.

5. Include edge values

Constructor bugs often appear at boundaries:

• zero addresses
• zero amounts
• maximum values
• empty arrays
• duplicate entries
• mismatched lengths

6. Test deployment under the intended sender

If the constructor uses msg.sender, make sure the test controls who deploys the contract. Otherwise, ownership assertions may pass accidentally for the wrong reason.

Common mistakes to avoid

Constructor tests are often too shallow. Watch out for these mistakes:

• Only checking that deployment succeeds

A successful deployment does not prove the state is correct.

• Ignoring inherited initialization

Base constructors may silently set important values.

• Using hardcoded assumptions about msg.sender

The deployer in a test may differ from the deployer in production.

• Skipping revert tests for invalid inputs

If the constructor accepts user-provided configuration, invalid cases should be tested explicitly.

• Not checking immutables

immutable variables are easy to trust and forget, but they are central to deployment correctness.

When constructor tests are not enough

Constructor assertions are necessary, but they are not a substitute for broader deployment checks. If your contract relies on post-deployment setup, you should also test:

• initializer functions for upgradeable patterns
• post-deployment role assignment
• script-driven configuration
• integration with external contracts
• migration from previous versions

Constructor tests prove that the contract starts correctly. They do not prove that the full system is configured correctly after deployment.

A compact checklist for deployment assertions

Use this checklist when reviewing a constructor test suite:

• [ ] All constructor arguments are validated
• [ ] All stored values are asserted after deployment
• [ ] All revert branches are covered
• [ ] msg.sender behavior is tested if relevant
• [ ] Inherited constructors are included
• [ ] Computed values are checked with exact expectations
• [ ] Edge cases are covered for zero and boundary values

If you can check every box, your deployment tests are likely doing real work.

Conclusion

Constructor testing is one of the highest-value forms of Solidity testing because it protects the contract before any user interaction occurs. By asserting initial state, validating inputs, and checking inherited setup, you can catch deployment-time mistakes that would otherwise survive into production.

Treat the constructor as part of your public API. If it defines the contract’s starting conditions, it deserves the same level of testing discipline as any external function.

Learn more with useful resources

• Foundry Book: Testing
• Solidity Documentation: Contracts
• OpenZeppelin Contracts