4.6 change in Do behavior broke my unittests

[flierh]

I used to be able (before version 4.6.0) to do:

Fixture.Build()
.With(cc => cc.PersonID)
.Do(cc => cc.Person = new PersonClass(cc.PersonID))

where I could use the generated cc.PersonID to create a new PersonClass.

With version 4.6.0 this no longer works. The PersonID passed to the new PersonClass is zero.

[zvirja]

Hi @flierh,

Thanks for reporting the issue. I've investigated it carefully and found that indeed the observable behavior has changed. It's a pity we didn't have tests covering that, so it sneaked out from my eyes 😢 I've created an issue to add tests for that.

Sorry for breaking your existing code withing the same major version. If I had tests, I would probably resist from the breaking changes even if it looked like a bug.

In fact, the new behavior is correct and that's the previous behavior which is wrong. The order of the callback invocations is following:

• Constructor
• Do() callbacks
• With callbacks
• AutoProperties callbacks

We have the issue #988 to add a callback after auto-properties assignment.

It suddenly appeared that previous implementation was not aligned under the hood, so With() callback was invoked before the Do() callback. Moreover, only the overload without explicit value was behaving like that - the With(x => x.Prop, value) overload was invoked after the Do() as it should.

Given that previous implementation suffered from the properties re-assignment (properties were changed after you introspected them in the Do() callback), I can suggest you to use the newly added With overload taking a factory method:

fixture.Build<Something>()
       .With(x => x.Person, (Guid id) => new PersonClass(id))

It will also look much nicer and concise and should work the same.

Let me know whether it works for you.

Thanks.

[Kralizek]

Today I learned that invocations are not executed following the order of writing.

@zvirja
Maybe something that can be fixed with a stronger compiler check?

Also, I'm not sure the new overload helps. In the example in the OP, there are two properties where only one is independent (the other uses the first's value).

Whilst it might make sense for the test, it is to be noted that the proposed workaround is not a perfect translation.

[MisinformedDNA]

I just got tripped up on this. Whatever the order is "supposed" to be, how are users supposed to know that? I fully expected that the operations would happen in order.

[zvirja]

Maybe something that can be fixed with a stronger compiler check?

I'm not sure I see how it could be done. Could you elaborate please a bit more?

Whilst it might make sense for the test, it is to be noted that the proposed workaround is not a perfect translation.

Sure! That's why we will implement #988 one day 😉

[Kralizek]

Maybe something that can be fixed with a stronger compiler check?

I'm not sure I see how it could be done. Could you elaborate please a bit more?

Oh sorry for the delay... I missed this question. What I meant is trying to use a stronger Fluent API so that the sequence of operations is commanded by the API and checked at compile time.

I did something similar here: https://github.com/emgdev/lambda-local-runner/blob/master/src/EMG.Lambda.LocalRunner/IRunnerBuilder.cs