Compiling, Testing, and Continuous Integration for Sui Developers Problem: You can write Move smart contracts and a TypeScript frontend, but getting them to work together in a clean, automated workflow is messy. You probably juggle between CLI commands, manual builds, and fragile test setups — which makes bugs slip into production. 😩

Goal: Build a deterministic pipeline where everything flows: ➡️ Compile Move packages → ✅ Run Move unit tests → 🔗 Run TypeScript integration tests → 🤖 Automate in CI/CD.

This guide shows you how to set up a bulletproof workflow for Move + TypeScript projects on Sui.

---

1) Local build and test flow ⚡

Before you even think about CI, you need a reliable local loop:

1. Move compilation

sui move build --path ./move

• Compiles your Move modules.
• Produces bytecode + ABI → which your frontend/SDK consumes.

2. Run Move unit tests

sui move test --path ./move

• Executes #[test] functions in your Move modules.
• Great for logic validation without deploying.

3. Export artifacts for frontend

• Keep outputs in build/ or artifacts/.
• Your TypeScript SDK should always reference ABI from this build (not a stale copy).

👉 Local rule of thumb: Never commit frontend code pointing at an old ABI. Always recompile after Move changes.

---

2) TypeScript integration testing 🧑‍💻

Once Move logic compiles, test it end-to-end with your frontend:

1. Add a testing framework:

npm i --save-dev jest ts-jest @types/jest

(or use Mocha if you prefer).

2. Connect to local devnet or a dockerized testnet:

• CI can spin this up.
• Local devnet ensures deterministic state.

3. Example test (Jest):

import { JsonRpcProvider, devnetConnection } from "@mysten/sui.js";

const provider = new JsonRpcProvider(devnetConnection);

test("fetch coin objects", async () => {
  const objects = await provider.getOwnedObjects({ owner: "0x123..." });
  expect(objects.length).toBeGreaterThanOrEqual(0);
});

4. Use fixture accounts:

• Pre-fund them with devnet faucet or seed via CLI.
• Keeps tests reproducible.

💡 Tip: Write tests for both happy paths and error paths. Don’t just test “success” — test insufficient gas, invalid ownership, etc.

---

3) CI Setup (GitHub Actions Example) 🤖

Now let’s automate it! A minimal GitHub Actions pipeline:

name: CI

on: [push, pull_request]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18

      - name: Set up Rust
        uses: actions-rs/toolchain@v1
        with:
          toolchain: stable

      - name: Install dependencies
        run: npm ci

      - name: Start Sui Devnet
        run: sui start --background

      - name: Build Move
        run: sui move build --path ./move

      - name: Run Move tests
        run: sui move test --path ./move

      - name: Run TS tests
        run: npm test

✅ Steps:

1. Install Node.js + Rust.
2. Start local devnet.
3. Build & test Move.
4. Run TypeScript integration tests.

---

4) Determinism & caching ⚡🚀

CI should be fast and reliable. Speed it up with caching:

• Cache node_modules and Rust Cargo build artifacts.
• Persist Move build artifacts between steps.
• Use GitHub’s built-in actions/cache for smarter caching.

👉 This avoids re-downloading and rebuilding everything on each push.

---

5) Troubleshooting tips 🛠️

Even with CI, things can break. Here’s a quick guide:

• Node failing to start in CI → Bump resources, ensure ports aren’t already used.

• ABI mismatch → Always generate frontend ABI from exact sui move build used in deploy. Don’t copy-paste.

• Flaky tests → Seed deterministic accounts, mock randomness where possible, isolate external dependencies.

• Slow pipeline → Add caching layers, avoid reinstalling dependencies unnecessarily.

---

Final Thoughts 🌟

By following this flow, you get:

• Move logic tested in isolation ✅
• Frontend verified against real contracts 🔗
• Automated CI/CD that ensures every push is safe 🚦

The result? Confidence. Your contracts and dApps won’t break silently, and your team spends less time debugging “it works on my machine” problems. 🎯