As an XAF Developer, What Should I Actually Test?

This is a story about testing XAF applications — and why now is finally the right time to do it properly.

With Copilot agents and AI-assisted coding, writing code has become cheaper and faster than ever. Features that used to take days now take hours. Boilerplate is almost free.

And that changes something important.

For the first time, many of us actually have time to do the things we always postponed:

documenting the source code,
writing proper user manuals,
and — yes — writing tests.

But that immediately raises the real question:

What kind of tests should I even write?

Most developers use “unit tests” as a synonym for “tests”. But once you move beyond trivial libraries and into real application frameworks, that definition becomes fuzzy very quickly.

And nowhere is that more obvious than in XAF.

I’ve been working with XAF for something like 15–18 years (I’ve honestly lost count). It’s my preferred application framework, and it’s incredibly productive — but testing it “as-is” can feel like wrestling a framework-shaped octopus.

So let’s clarify something first.

You don’t test the framework. You test your logic.

XAF already gives you a lot for free:

CRUD
UI generation
validation plumbing
security system
object lifecycle
persistence

DevExpress has already tested those parts — thousands of times, probably millions by now.

So you do not need to write tests like:

“Can ObjectSpace save an object?”
“Does XAF load a View?”
“Does the security system work?”

You assume those things work.

Your responsibility is different.

You test the decisions your application makes.

That principle applies to XAF — and honestly, to any serious application framework.

The mental shift: what is a “unit”, really?

In classic theory, a unit is the smallest piece of code with a single responsibility — usually a method.

In real applications, that definition is often too small to be useful.

Sometimes the real “unit” is:

a workflow,
a business decision,
a state transition,
or a rule spanning multiple objects.

In XAF especially, the decision matters more than the method.

That’s why the right question is not “how do I unit test XAF?”
The right question is:

Which decisions in my app are important enough to protect?

The test pyramid for XAF

A practical, realistic test pyramid for XAF looks like this:

Fast unit tests for pure logic
Unit tests with thin seams around XAF-specific dependencies
Integration tests with a real ObjectSpace (confidence tests)
Minimal UI tests only for critical wiring

Let’s go layer by layer.

1) Push logic out of XAF into plain services (fast unit tests)

This is the biggest win you’ll ever get.

The moment you move important logic out of:

Controllers
Rules
ObjectSpace-heavy code

…testing becomes boring — and boring is good.

Put non-UI logic into:

Domain services (e.g. IInvoicePricingService)
Use-case handlers (CreateInvoiceHandler, PostInvoiceHandler)
Pure methods (no ObjectSpace, no View, no security calls)

Now you can test with plain xUnit / NUnit and simple mocks or fakes.

What is a service?

A service is code that makes business decisions.

It answers questions like:

“Can this invoice be posted?”
“Is this discount valid?”
“What is the total?”
“Is the user allowed to approve this?”

A service:

contains real logic
is framework-agnostic
is the thing you most want to unit test

If code decides why something happens, it belongs in a service.

2) Unit test XAF-specific logic with thin seams

Some logic will always touch XAF concepts. That’s fine.

The trick is not to eliminate XAF — it’s to isolate it.

You do that by introducing seams.

What is a seam?

A seam is a boundary where you can replace a real dependency with a fake one in a test.

A seam:

usually contains no business logic
exists mainly for testability
is often an interface or wrapper

Common XAF seams:

ICurrentUser instead of SecuritySystem.CurrentUser
IClock instead of DateTime.Now
repositories / unit-of-work instead of raw IObjectSpace
IUserNotifier instead of direct UI calls

Seams don’t decide anything — they just let you escape the framework in tests.

What does “adapter” mean in XAF?

An adapter is a very thin class whose job is to:

translate XAF concepts (View, ObjectSpace, Actions, Rules)
into calls to your services and use cases

Adapters:

contain little or no business logic
are allowed to be hard to unit test
exist to connect XAF to your code

Typical XAF adapters:

Controllers
Appearance Rules
Validation Rules
Action handlers
Property setters that delegate to services

The adapter is not the brain.
The brain lives in services.

What should you test here?

Appearance Rules
Test the decision behind the rule (e.g. “Is this field editable now?”).
Then confirm via integration tests that the rule is wired correctly.
Validation Rules
Test the validation logic itself (conditions, edge cases).
Optionally verify that the XAF rule triggers when expected.
Calculated properties / non-trivial setters
Controller decision logic once extracted from the Controller

3) Integration tests with a real ObjectSpace (confidence tests)

Unit tests prove your logic is correct.

Integration tests prove your XAF wiring still behaves.

They answer questions like:

Does persistence work?
Do validation and appearance rules trigger?
Do lifecycle hooks behave?
Does security configuration work as expected?

4) Minimal UI tests (only for critical wiring)

UI automation is expensive and fragile.

Keep UI tests only for:

Critical actions
Essential navigation flows
Known production regressions

The key mental model

A rule is not the unit.
The decision behind the rule is the unit.

Test the decision directly.
Use integration tests to confirm the glue still works.

Closing thought

Test your app’s decisions, not the framework’s behavior.

That’s the difference between a test suite that helps you move faster
and one that quietly turns into a tax.