4

I am designing an analytics application using domain driven design and test driven development. I am having difficulty modeling the following requirement:

The application shows a workitem's state. States are modeled as a composition of a superstate and a substate.

  • Superstate can be any of the following: "A", "B", "C", "D"
  • Substate can be any of the following: "X", "Y", "Y1", "Y2", "Z"

Each superstate has a set of valid substates:

  • Valid substates of "A" are "Y", "Z".
  • Valid substates of "C" are "X", "Y1", "Y2", "Z".
  • All other superstates have the following valid substates: "X", "Y", "Z"

I devised a model which includes the following aggregate: UML class diagram showing a "Workitem" class referencing a "Workitem State" class, in turn referencing two enum classes: "Superstate" and "Substate". The enums value are those described earlier

Workitem is the aggregate root and Workitem State is a value object. A check at the instantiation of Workitem will ensure that the state has a valid combination of superstate and substate.

Since I'm following a TDD approach, the implementation of the state validation logic should be preceded by the definition of a corresponding test(psedudo-code):

#test module

func test_state_validity():
   # tests all combinations of superstate and substate
   
   for sup in SuperState:
      for sub in SubState:
         try:
            s = State(sup, sub)
            assert sub in get_allowed_substates(sup)
         except InvalidStateException:
            assert sub not in get_allowed_substates(sup)

Then i wrote the following implementation(psedudo-code):

# states module

enum SuperState:
   A,
   B,
   C,
   D

enum SubState:
   X,
   Y,
   Y1,
   Y2,
   Z

class WorkitemState:
   superstate: SuperState
   substate: SubState

   def create_state(superstate, substate):
      if substate in get_allowed_substates(superstate):
         return WorkitemState(superstate, substate)
      else:
         raise InvalidStateException


func get_allowed_substates(superstate):

   switch superstate:
      case SuperState.A:
            return (SubState.Y, SubState.Z)

      case SuperState.C:
            return (SubState.X, SubState.Y1, SubState.Y2, SubState.Z)

      case _:
            return (SubState.X, SubState.Y, SubState.Z)

In compliance with DDD, the invariant has been enforced within the Domain Layer (in the aggregate root). In compliance with TDD, a corresponding test has been defined as well.

This made me realize there is significant overlap between the validation logic within the domain objects and unit tests (in my case I tried to keep it DRY by having both refer to the function get_allowed_substates).

My questions are:

  • is writing tests for the domain model redundant, and thus be avoided? (in general and in this specific case)
  • is it a sensible choice to test all possible combinations of superstate and substate, or should I rather restrict the scope of the test? e.g. all valid combinations plus a few edge cases such as {("A","X"), ("C","Y"), ("B", "Y1")}

Notes:

  1. differently from the example, my actual use case has ~100 possible super/substate combinations. The definition of superstates and their allowed substates is unlikely to change i nthe future. Most states tend to have the same set of allowed substates, with just a couple of excpetions
  2. WorkitemState is a simple valueobject intended for display. It is not an implementation of a state pattern and doesn't contain complex behaviour (this is just an analytics tool, state changes are managed by an external, pre-existing application)
  3. the state of a workitem is retrieved from an external database, where it is stored as a string (e.g. "A Y"), which is parsed into a WorkitemState object
Improve this question

4 Answers 4

Reset to default
4

What you want to avoid testing is configuration, and here the allowed sub states could be considered configuration.

Let rearrange your domain objects so you have:

SuperState
   string id
   string[] allowedSubStates

State
   SuperState super
   SubState sub
   IsValid() { return super.allowedSubStats.Contains(sub.id); }

Now You want at least two unit tests for IsValid, plus maybe some nulls etc. But there's no point testing all possible combinations. That's just the Config for the various states and we can imagine this changing over time or even being user configurable.

Consider the opposite case though, where instead of just a list of allowed sub states there are some rules about the substates. eg:

SuperState_triangles //sub states must have three sides!
   string id
   IsValid(SubState sub) { return sub.sides.count == 3; }

State
   SuperState super
   SubState sub
   IsValid() { return super.IsValid(sub); }

Now I need tests for the rules, so I will have to try various sided sub states with the triangle super state etc. It might well be worth having a whole bunch of tests for common cases.

Improve this answer
5
  • I hadn't thought of expressing requirements through configuration. The DDD book says "a FACTORY is responsible for ensuring all invariants are met for the object or AGGREGATE it creates". Such statement could be reconciled with your approach by seeing it as the factory/constructor delegating the enforcement of the invariant to the configuration object Commented Jun 21, 2025 at 23:25
  • Why would I want to avoid testing configuration? Commented Jun 21, 2025 at 23:38
  • Hmm i think maybe you are reading too much into that sentence about factories. The key thing is that your invariants are enforced in code rather than a database. Commented Jun 22, 2025 at 9:15
  • Avoid testing configuration because all the different configurations should be valid. You'll just end up as you have here with millions of tests that just duplicate your code and don't test anything. Commented Jun 22, 2025 at 9:16
  • *note : I should add some get out of jail free cards before I get down voted. I'm talking about unit tests and TDD here, so smoke tests and health checks "is this instance connected to the right db", "is the live logging working" etc they are fine. Unit Tests dont know the deployed configuration of your app Commented Jun 22, 2025 at 9:18
2

Since I'm following a TDD approach, the implementation of the state validation logic

In a TDD approach, I would expect you to be concentrating your attention on the implementation of behavior, rather than the implementation of state.

Which is to say, that your example of having a test for get_allowed_substates that explores the entire range of inputs is "fine" (I have doubts about the structure of this test: the api you have been "driven" to, and how well the test serves as documentation for how the method is expected to work).

But as a function, what is this for? If the state machine is under the control of your program, then reaching an "invalid" state really means that there has been a programmer error somewhere - that some implementation of a transition in the state machine didn't realize the intended state.

On the other hand, if you are dealing with a source of "untrusted" state data, then you probably out to have a parser somewhere close to the boundary where the untrusted data enters the system, and you should be test driving the parser.

(Now, in fairness, there is a subset of the TDD community that loves starting with small "units" that are driven into existence in isolation -- you might be doing that, but it isn't obvious from this example that you are doing this and keeping a specific client in mind; one of the reasons that I prefer working "outside in" is that you get alignment with the client context "for free".)

This made me realize there is significant overlap between the validation logic within the domain objects and unit tests

Yeah, this kind of thing is common and normal - it has to do with the fact that we have the same predicate being used for two different ideas.

  • In our parser, we're trying to figure out if some general purpose data structure is aligned with our narrower range of expected values (example: we're receiving information using a general purpose integer data type; but our narrower expectation is that the integer shall always be positive - thus, roughly half of the space of values that fit in the general purpose data type are "invalid", and need not-on-the-happy-path handling).

  • In our domain types, we're using a constructor to ensure that some data constraint only needs to be checked once, and the validation within the constructor is a defensive programming technique intended to catch errors in our parsing code.

(Warning: untested pseudo-code written in an imaginary programming language)

class TrustedData:
  def __init__(untrustedData):
    FailFast.programmerError(...) if not valid(untrustedData)
    ...

def parsing(untrustedData):
  if valid(untrustedData):
    happyPath( TrustedData(untrustedData) )
  else:
    # handle the usual case that we've gotten bad information
    # from our untrusted source

What we're really doing in the TrustedData constructor is checking that the programmer who wrote the parsing function did the right thing.

If you look through the older literature, the code in the constructor might look instead like

class TrustedData:
  def __init__(untrustedData):
    assert valid(untrustedData)

Where the assert line would be completely removed from the production code (ex: in C code, those lines would normally be elided by the preprocessor before the source was passed to the compiler).

is writing tests for the domain model redundant, and thus be avoided?

Typically, in DDD, the domain model is the thing that's real; it's where the important logic lives, and that's the code that changes regularly as the needs of the business evolve -- so that's an important area to be able to make changes without introducing faults. TDD's twin goals of (a) improving the design so that faults are introduced less frequently and (b) producing tests so that faults are detected both quickly and cost effectively play well here.

But specifically for the case of something like a programmerError detector, the cost benefit ratio of having "tests" is not quite the same as it would be in code that has a lot of branches.

Horses for Courses

is it a sensible choice to test all possible combinations of superstate and substate

From a TDD perspective? Mostly no, in my experience -- you don't typically learn anything interesting about the design by spamming an infinite number of input combinations.

From a testing perspective? Maybe. See "Property Based Testing" in the literature. My experience is that typing-the-same-thing-in-two-places tests aren't especially valuable, and that the cost benefit ratio gets really bad if the answer isn't stable.

At one end of the spectrum you have "the answers are really stable, but we are constantly changing how we calculate them", and at the other end you have "the answers are always changing, but the calculation is always so simple that there are obviously no deficiencies" -- for the latter case, you may have more cost effective alternatives than maintaining a suite of "automated" tests.

WorkitemState is a simple valueobject intended for display. It is not an implementation of a state pattern and doesn't contain complex behaviour (this is just an analytics tool, state changes are managed by an external, pre-existing application)

In that case, you probably don't have a "domain model" -- your code is primarily about labeling information so that you can be sure that the right things are being displayed in the right places.

For instance, you probably don't have an "aggregate root" here, because an aggregate is "a cluster of objects that we treat as a unit for the purpose of data changes" and your program isn't responsible for data changes; you are taking the data as is and preparing a report from it.

(In some parts of the DDD community, you'll find people talking about read models vs write models; aggregates are a pattern that makes a certain amount of sense when writing down new information from the outside world, but don't necessarily offer very good ROI when you are simply rendering information written down previously).

What you've shown here is "just" an id/superstate/substate tuple; whether that's a single value object, or a graph of value objects... well, there are trade offs; but from your description, you'll really want it to look more like an immutable value copied from some outside source than a local entity that can be modified.

But before diving too deeply into how to test this, you might want to explore how things are expected to change over time. For example, if the rules about which combinations of states changes, are you expected to need to release a new version of your code to make things work? When the answer is "no, the old release should work with the new rules" (which is, in my experience, the common case), then you want to be cautious about over fitting your solution to today's rule set.

Improve this answer
3
  • My use case definitely falls under the "untrusted data source" scenario you have described (see notes no.2,3 I recently added) Commented Jun 21, 2025 at 10:40
  • I see: since my application only performs read operations, there is no need for a domain model to enforce invariants. The reason behind my obstinacy in using DDD is my use case: the analytics tool has to make reports on a legacy application which has a flawed model that fails to enforce invariants which have been discovered after it was deployed in production. The purpose of the reports is to highlight violations of these invariants and help in correcting data accordingly (thus easing migration towards a better model). Now I see how these "newfound invariants" are domain objects as well Commented Jun 26, 2025 at 20:19
  • The focus of my original question was the modeling of state objects, and i'm sold on incorporatring them into configuration as you and others have suggested. While not as straightforward, your answer(s) gave me deeper insight, and made me realize that I have other flaws within my model which deserve a post on their own Commented Jun 26, 2025 at 20:26
1

Follow the zero-one-infinity rule. It states the only numbers allowed in a design are 0, 1, or as many as you like.

Thus, both your super and sub state lists should be designed to be arbitrarily large. Your design, and its tests, should not statically reflect one particular set of either.

However, this means you must express the particular states in some other way than hard coding them into the design.

Improve this answer
0

Is writing tests for the domain model redundant?

Not at all, but you've done it the wrong way. If you reuse the same function get_allowed_substates in both your domain logic and your tests, you're not really testing anything.

Use real, manually written values to test your business logic. In fact, your tests should verify logic inside the get_allowed_substates function.

Is it a sensible choice to test all possible combinations?

It depends on the business context. If it is critical, then yes — test all combinations. You can use data-driven testing to keep things clean and maintainable.

If it's not critical, testing just a few cases per behavior (e.g. a valid and an invalid scenario for SuperState.A). It's more about test coverage.

Improve this answer
5
  • 1
    Use real, manually written values to test your business logic It would be unpractical to write one assertion per combination (see note #1). Writing any less than that could let an illegal combination silently slip past the test Commented Jun 20, 2025 at 15:03
  • 1
    @Afelium My point is that it depends on the business. If it is not critical , just write a few positive and negative tests (4-5 will be enough), just for covering raising errors in the constructor. This is the place that we want to test. But if it's critical maybe something like All-pairs testing can help. github.com/joebmt/allpairs - Generate All-Pair test combinations library. If you reuse get_allowed_substates function, your test has zero value. Commented Jun 20, 2025 at 15:24
  • 1
    I’d rather see tests that test both sides of boundaries and assumed the code worked against arbitrary length lists. Commented Jun 20, 2025 at 22:48
  • My use case is that of an analytics tool; making sure that invalid states raise exceptions is critical because it is a telltale sign that the analytics application might not be parsing states correctly. But as @VoiceOfUnreason pointed out, I might have to weigh the costs vs benefits of this "combination test", or test another thing entirely Commented Jun 21, 2025 at 10:53
  • @Afelium If supporting the full "combination test" is hard, and the combinations change often, you can generate the dataset at runtime in your test code (though it might be slower). Also, you can duplicate the get_allowed_substates logic inside the tests to be sure in writen code. codewithjason.com/why-duplication-is-more-acceptable-in-tests Commented Jun 21, 2025 at 19:19

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.