Testing Smart Contracts with Remix: Revenue Sharing Contract

Smart contracts are the backbone of decentralized applications (dApps) on the Ethereum blockchain. Before deploying any contract to the mainnet, thorough testing is essential to ensure functionality, security, and reliability. One of the most accessible tools for this task is Remix IDE, an open-source, browser-based integrated development environment designed specifically for writing, compiling, and testing Solidity smart contracts.

In this guide, we’ll walk through how to test a classic example: the Revenue Sharing Contract, using Remix. By the end, you’ll understand how to deploy and interact with a smart contract in a safe environment—perfect for beginners and developers looking to refine their workflow.

What Is Remix IDE?

Remix is the official web-based IDE provided by the Ethereum community. It offers a comprehensive suite of tools for smart contract development, including:

A built-in Solidity compiler
Runtime environment with JavaScript VM
Contract deployment and execution interface
Static analysis and debugging features

These capabilities allow developers to test contracts locally without spending real Ether or interacting with the main blockchain.

👉 Discover how blockchain developers streamline contract testing using powerful tools.

Understanding the Revenue Sharing Contract

The revenue sharing contract is a foundational example in blockchain development. Its purpose is simple yet practical: distribute funds evenly among a predefined group of Ethereum addresses.

How It Works

When the contract is deployed:

A fixed array of wallet addresses is set.
Anyone can send Ether to the contract.
The received funds are split equally among all designated addresses.

This model can be used in real-world scenarios like profit distribution among partners, crowdfunding payouts, or decentralized team bonuses.

The original version of this contract appears in Blockchain Applications: A Hands-On Approach by A. Bahga and V. Madisetti, written for Solidity ^0.4.8. However, due to breaking changes in later versions, we’ve updated it to Solidity ^0.5.11 for compatibility with modern compilers.

RevenueSharing.sol (Solidity ^0.4.8) – Legacy Version

pragma solidity ^0.4.8;

contract RevenueSharing {
    address[] public shareholders;

    function RevenueSharing(address[] _addresses) {
        shareholders = _addresses;
    }

    function shareRevenue() public {
        uint256 amount = msg.value / shareholders.length;
        for (uint8 i = 0; i < shareholders.length; i++) {
            shareholders[i].transfer(amount);
        }
    }
}

🔍 Note: This version will throw errors in newer Solidity compilers due to syntax deprecations and security updates.

RevenueSharing.sol (Solidity ^0.5.11) – Updated Version

pragma solidity ^0.5.11;

contract RevenueSharing {
    address payable[] public shareholders;

    constructor(address payable[] memory _addresses) public {
        shareholders = _addresses;
    }

    function shareRevenue() public payable {
        uint256 amount = msg.value / shareholders.length;
        for (uint8 i = 0; i < shareholders.length; i++) {
            shareholders[i].transfer(amount);
        }
    }
}

Key Changes Explained:

address[] → address payable[]: Only payable addresses can receive Ether via .transfer().
function RevenueSharing(...) → constructor(...): Constructor syntax was standardized in Solidity 0.5.x.
Added memory keyword for array parameter: Required for reference types in function arguments.
msg.value remains unchanged but now operates under stricter type-checking rules.

Understanding these differences helps you migrate legacy contracts and avoid common compilation errors.

Step-by-Step: Deploying the Contract in Remix

Let’s now deploy and test the updated contract using Remix IDE.

1. Open Remix IDE

Go to remix.ethereum.org (no download or setup needed).

2. Create a New File

Click the File Explorer icon → Create a new file named RevenueSharing.sol. Paste the updated Solidity code above.

3. Compile the Contract

Navigate to the Solidity Compiler tab:

Select compiler version 0.5.11.
Click Compile RevenueSharing.sol.

After successful compilation, click Details to view:

Bytecode: Raw machine-level code for deployment.
ABI (Application Binary Interface): Defines how your app interacts with the contract.
Web3Deploy: Snippet for integrating into Web3.js projects.

These outputs are critical when deploying contracts externally or connecting frontends.

👉 Learn how developers use ABI data to connect dApps securely.

Deploying to JavaScript VM

Remix provides several environments; we’ll use JavaScript VM—a simulated blockchain that requires no mining or network fees.

Steps:

Go to the Deploy & Run Transactions tab.
In the Environment dropdown, select JavaScript VM.
Under Contract, choose RevenueSharing from the dropdown.
Input shareholder addresses:

[
  "0xCA35b7d915458EF540aDe6068dFe2F44E8fa733c",
  "0x14723A09ACff6D2A60DcdF7aA4AFf308FDDC160C",
  "0x4B0897b0513fdC7C541B6d9D7E929C4e5364D2dB",
  "0x583031D1113aD414F02576BD6afaBfb302140225"
]

These are test accounts preloaded in Remix’s VM—no private keys required.

Click Deploy.

You now have a running instance of your revenue-sharing contract!

Interacting with the Deployed Contract

Once deployed, you can interact with its functions directly from the UI.

Check Shareholders List

Click on shareholders to expand and verify all four addresses are correctly stored.

Send Funds and Trigger Distribution

In the deployed contract section, find the shareRevenue function.
Set Value to 40 ETH (use dropdown to select Ether).
Ensure Account 1 (first test wallet) is selected.
Click transact.

Expected Outcome:

40 ETH is sent from Account 1.
Each of the four shareholders receives 10 ETH.
Account balances update instantly in the VM.

💡 Pro Tip: You can modify logic to give weighted shares—e.g., one partner gets double—by adjusting distribution inside shareRevenue().

Frequently Asked Questions (FAQ)

Q1: Why should I test smart contracts before deployment?

Testing ensures your contract behaves as expected and prevents irreversible bugs or vulnerabilities. Once deployed on Ethereum mainnet, contracts cannot be modified—only upgraded via complex patterns.

Q2: Can I lose real money while using Remix?

No—if you use JavaScript VM or injected Web3 with testnets like Sepolia, no real funds are at risk. Always avoid sending mainnet Ether during early testing phases.

Q3: What does “payable” mean in Solidity?

A payable function can receive Ether. Without this keyword, msg.value will cause a compile-time error.

Q4: How do I fix “TypeError: Type address[4] memory is not implicitly convertible”?

Ensure your array is declared as address payable[] and passed with correct memory specification in constructor calls.

Q5: Is Remix suitable for team collaboration?

While Remix is ideal for learning and prototyping, larger teams often use Hardhat or Foundry with Git integration for version control and CI/CD pipelines.

Q6: Can I connect Remix to MetaMask?

Yes! Use the Injected Provider environment in Remix to connect MetaMask and deploy contracts on live testnets or mainnet securely.

Final Thoughts

Testing smart contracts using Remix lowers the barrier to entry for blockchain development. With intuitive tools and real-time feedback, you can build confidence in your code before going live.

Whether you're building a simple revenue-sharing mechanism or a complex DeFi protocol, mastering Remix is a crucial first step.

As blockchain adoption grows, so does the demand for secure, well-tested contracts—equip yourself with the right tools today.

👉 Start building and testing secure smart contracts with industry-leading platforms.

Core Keywords Used:

Remix IDE
Smart Contract Testing
Revenue Sharing Contract
Solidity
Deploy Smart Contract
JavaScript VM
Ethereum
Blockchain Development

This guide integrates SEO-friendly keywords naturally while maintaining technical accuracy and reader engagement—ideal for both search visibility and user comprehension.