I am not sure I agree with your observation that such a
pattern is needed.
In my opinion the creation process of your object should
be a part of one of your layers
(domain model,business layer or [put here some fancy
layer name])
If you need too much lines of code to create an object
then maybe you need to add a new object to your domain
model.
Tomer, doesn't this depend on your choice of test
isolation? In theory, unit tests should not depend on
one another. They should set up a
"known" state, execute the test and
after compare the before and after states to ensure that
the test succeeded. By this principle it is not
acceptable to use any part of the domain being tested to
perform the "state setup" and
subsequent "state comparisons". As the
system growns in size, you realize that there is a lot
of duplication in these setup and before and after
comparisons. Hence you refactor the setup and Assert
logic into helper classes. These too can get
"out of hand" and Roy is simply giving
guidance as to possible containment patterns. The real
trick is to build your test code with the same level of
care that you put into the production code. This really
starts to pay off as the number of tests grows.