New Upload weather data from web services into TM1/Planning Analytics โ€” Read the post โ†’

๐Ÿงช Automated Testing for TM1

Automated unit testing has been standard practice in software engineering for decades. With Arc+, TM1 developers get the same discipline โ€” repeatable tests that run before every release, catching regressions in rules, processes, and data loads before they reach production.

This section covers the Test Hub and the building blocks that sit inside it.

Test Hub

The central place where every aspect of TM1 testing lives โ€” writing tests, organising them, running them, and reviewing coverage.

Why it matters: testing is consolidated in one consistent surface instead of scattered across spreadsheets, screenshots, or ad-hoc TI processes. Anyone on the team can run the suite and trust the result.

Building blocks of the Test Hub

Collections

Group related unit tests into a single runnable suite that executes them in sequence.

Why it matters: a full regression test becomes a one-click operation, reproducible by anyone on the team, every time.

Categories

Logical grouping by purpose โ€” data load tests, rule tests, dimension tests, export tests, and so on.

Why it matters: large test suites stay manageable as they grow. Failures can be triaged by category before drilling into individual tests.

Unit Tests

Individual checks that verify a single behaviour โ€” a TI process loads the expected number of rows, a rule produces the expected value, an export produces the expected file structure.

Why it matters: when something breaks, the failing unit test points directly at the change that caused it. No more hunting through logs at 11pm.

Assertions

The actual comparisons inside a test โ€” expected versus actual cell values, row counts, error states, and so on.

Why it matters: assertions produce precise, repeatable failure messages. "Cube X cell Y returned 42, expected 100" is a far better starting point for investigation than "the report looks wrong".

Code Coverage

Reports which lines of which TI processes were exercised by your tests, and which were not.

Why it matters: you can see exactly where coverage is thin and prioritise additional tests there โ€” instead of guessing what is and isn't tested.

Summary

Bringing software-engineering testing discipline to TM1 produces fewer regressions, faster root-cause investigations when things do break, and a clear, evidence-backed measure of how well your model is covered. The Test Hub makes that practical for TM1 teams without requiring a separate testing tool.

For a hands-on walkthrough, see ๐ŸŽ“ Arc+ Training.