First principles or side by side: which testing approach fits your ETRM system?

Ask a testing team how they know a test has worked, and you'll usually get a technical answer. But strip the question back and something more fundamental sits underneath it: how do you know what the right answer should be in the first place?

If testing is doing something and checking the outcome against what you expected, then everything depends on where "expected" comes from. There are really only two places it can come from, and they lead to two very different approaches to testing an ETRM system.

Two ways to know the answer

The first is to work it out from scratch. You have a specification for how the system should behave, you understand the domain, and you reason from inputs to expected outputs independently of the system itself. Known inputs, known action, known result. This is first principles testing.

The second is to trust that the system is already working, and check that a change hasn't broken anything. You take two copies of the system, apply the change to one, run the same inputs through both, and check that both produce the same outputs. Same inputs, same action, same result. This is side by side testing (sometimes called comparison or regression testing).

Both are legitimate. Neither is better in the abstract. The right one depends almost entirely on the situation you're in.

When first principles fits

First principles testing is the only option when there's nothing to compare against. If you're implementing an ETRM platform for the first time, whether that's ION Openlink Endur, Allegro or another system, or replacing an existing one, there's no baseline to hold up as truth. You have to work out the expected results from the specification.

It's expensive to set up because someone has to genuinely understand the system well enough to predict its behavior. But it gives you two things that side by side can't.

The first is a fast find-fix cycle. Tests are narrow and targeted, so when a developer breaks something, the failing test tells you exactly what and where. Recreate, fix, move on.

The second is what's sometimes called living documentation. A well-written first principles test is effectively a readable statement of how the system should behave. And unlike a specification document, which quietly drifts out of date the moment someone changes the system, a test that's run successfully every night for a year is an accurate description of how the system actually works today. Some Trinitatum clients have first principles tests that have been running nightly for more than 10 years. That test suite is now a more reliable source of truth than any document.

When side by side fits

Side by side comes into its own for mature, complex systems that are already live and broadly working. Once a platform has been in production for a few years, say a long-established Endur, Allegro or comparable ETRM installation, reverse-engineering a full first principles test suite becomes impractical. Specifications aren't complete. The people who built the original logic have moved on. Some behavior is well understood in one team's heads and nowhere else.

For those systems, side by side is fast to set up and gives broad coverage quickly. You don't need to understand why a particular P&L number is what it is. You need to know that after a change, it's still the same. That's a much easier question to answer.

It also handles complexity well. When a report has 50 million rows across every trade in the book, no one is going to check that manually or derive each expected value from scratch. Comparing the two versions row by row, column by column, is something automation does easily.

Why most mature programs need both

In practice, most serious ETRM testing programs end up using both. Side by side gives you protection across the breadth of the system. First principles gives you depth and precision where it matters most, and it's the only credible way to test new functionality as it goes in.

The shape of the environments tends to differ too. First principles tests run on small, carefully constructed data sets, so teams often run many environments in parallel. Side by side tests run on full copies of production, so environments are heavier and there are fewer of them.

Neither shape is right or wrong. Both reflect what the tests are for.

Triangle is designed to support both approaches across the ETRM platforms it works with. The right choice should be shaped by your system’s circumstances, not limited by your testing platform’s strengths.