Skip to content
Skills Library
Programming · Testing

objectscript-tdd

/objectscript-tdd

Compile-test-fix loop for ObjectScript development. Use when writing or modifying ObjectScript classes.

Licence
MIT
Last repository change
25.10.2026

Assessment and security

100/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability25 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content35 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
Files in this package
1
Scripts
0
HTML comments
0
URLs in SKILL.md
0
Deprecation

No signals detected. Repository changed on 25.10.2026, without references to retired models or APIs.

Licence

MIT, open: use and modify while retaining author attribution.

What it does and when to use it

Compile-test-fix loop for ObjectScript development. Use when writing or modifying ObjectScript classes.

Original author description

Compile-test-fix loop for ObjectScript development. Use when writing or modifying ObjectScript classes.

How it works

  1. Purpose
  2. Process Flow
  3. Compile Command
  4. Key Principle
  5. Common Compile Errors and Fixes
  6. Related skills
Original SKILL.md headings · 70 lines, 448 words
SKILL.md preview
---
name: objectscript-tdd
tier: core
description: Compile-test-fix loop for ObjectScript development. Use when writing or modifying ObjectScript classes.
license: MIT
metadata:
  version: "1.0.0"
  author: InterSystems Developer Community
  compatibility: objectscript, iris, healthconnect
---

## Purpose

Close the feedback loop: write → compile → fix errors → run tests → fix failures → done.

## Process Flow

1. **Write** the class
2. **Review** — run objectscript-review skill first
3. **Compile** — run the compile command for this project
4. **If compile errors**: read the error, identify the line, fix it. Return to step 3.
5. **Run tests** — run the unit test suite
6. **If test failures**: read the failure message, fix the code or the test. Return to step 3.
7. **Done** when: compiles clean + all tests pass

## Compile Command

Use the objectscript MCP tool when available (check `/mcp`):

```text
iris_doc(mode="put", name="MyPackage.MyClass.cls", content="...", compile=true, namespace="USER")
```

Fallback when MCP is unavailable:

```bash
iris session IRIS -U USER "Do $System.OBJ.Load(\"<ClassName>.cls\",\"ck\")"
```

## Key Principle

Never present code to the user that hasn't compiled. If you can't compile (no IRIS access), flag this explicitly:

> ⚠️ No IRIS connection available — code is unverified. Recommend compiling before use.

A class that compiles clean has not been tested. The compiler does not check that a local is set before it is read, and it cannot check a method name built at runtime. Both of these compile with no error and fail when called:

```objectscript
ClassMethod Total(pA As %Integer, pB As %Integer) As %Integer
{
    Set tSum = pA + pB
    Quit tSun                  // <UNDEFINED> tSun at runtime
}

ClassMethod Dyn() As %String
{
    Quit $CLASSMETHOD("MyPackage.MyClass", "Nope")   // <METHOD DOES NOT EXIST> at runtime
}
```

A literal `..Nope()` is caught at compile time, but a dynamic call is not. Call every method you changed at least once, through `iris_execute` or a test, before you call it done.

## Common Compile Errors and Fixes

| Error                              | Cause                                       | Fix                               |
| ---------------------------------- | ------------------------------------------- | --------------------------------- |
| `#1043: QUIT argument not allowed` | `Quit <val>` inside TRY/CATCH               | Change to `Return <val>`          |
| `<COMMAND>` at runtime             | `Quit <val>` inside a For/While block       | Change to `Return <val>`          |
| `Expected a compilable class`      | Missing `Class` keyword or malformed header | Check class declaration line      |
| `Method does not exist`            | Intra-class call without `..`               | Add `..` prefix                   |
| `<UNDEFINED>` at runtime           | Variable used before SET                    | Initialize variable before use    |
| `Expected white space`             | Missing space after command keyword         | Add space: `Set x=1` not `Setx=1` |

## Related skills

- **objectscript-review** — run before compiling to catch common mistakes early
- **objectscript-unit-test** — writing %UnitTest scaffolding
- **objectscript-coverage** — measuring whether your test suite exercises the code (requires merged toolset)
- **objectscript-debugging** — when a test fails with a runtime error

Versions

The database has no other skills named objectscript-tdd.

Database snapshot: 13.11.2026 · package version 0ab66416b5c6 (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

  • 95objectscript-list-patterns
    ObjectScript %List, %ListOfDataTypes, $LISTBUILD, $LISTTOSTRING, $LISTNEXT patterns. Use when building, iterating, merging, or converting lists in ObjectScript.
  • 100objectscript-coverage
    Measure ObjectScript line coverage using iris_coverage. Use when a user asks about test coverage, coverage reports, or wants to know how well their test suite exercises their code.
  • 96tdd
    Use when implementing features or bug fixes test-first.
  • 90tdd-cycle
    Red-Green-Refactor TDD loop with mandatory false-positive check. Use when: test, TDD, red-green, failing test, write test first, test-driven.
  • 100test-driven-development
    Use when practicing TDD. Covers the red-green-refactor loop, choosing the next test, designing through tests, and when TDD is and is not the right approach. Trigger on "let's do tdd", "write the failing test first", "red green refactor", "what test should i write next". Do not…
  • 100tdd
    Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

Feedback and reports

Your message goes to Bartosz Sokoliński. An email address is needed only for a reply. See the privacy policy.