Make all default return values Dummies, even after Invokes or DoesNothing #830

Closed
blairconrad opened this Issue Aug 17, 2016 · 19 comments

Comments

Projects
None yet
3 participants
@blairconrad
Member

blairconrad commented Aug 17, 2016

Spun off from #806.

Currently, an unconfigured method with a return value will return a Dummy of the appropriate type when called.

However, as soon as we start building a rule (for example, when we add an Invokes behaviour to the method), we create a rule that will return the "default value" for the type, as we can see in BuildableCallRule's constructor. GetDefaultValue returns null for a reference type or an instance for a value type.

And then if we decide to have the method DoesNothing, the rule is modified so that it will not set the return value at all (and this is the cause of the bug that @thomaslevesque found).

I think that all three situations should use the "unconfigured behaviour" and return a Dummy (or nothing for a void of course).

@blairconrad

This comment has been minimized.

Show comment
Hide comment
@blairconrad

blairconrad Aug 17, 2016

Member

I struggled with the bug/enhancement labels for this one. In the end, I figured if we thought that #806 was a bug, because users are forced to specify a return value or get undesired behaviour, then so too is this a bug. I could be persuaded.

Member

blairconrad commented Aug 17, 2016

I struggled with the bug/enhancement labels for this one. In the end, I figured if we thought that #806 was a bug, because users are forced to specify a return value or get undesired behaviour, then so too is this a bug. I could be persuaded.

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Aug 17, 2016

Member

Marking as on-hold until we decide we want to go ahead with 3.0.

Member

adamralph commented Aug 17, 2016

Marking as on-hold until we decide we want to go ahead with 3.0.

@blairconrad

This comment has been minimized.

Show comment
Hide comment
@blairconrad

blairconrad Aug 17, 2016

Member

Ah. I should've thought of that. Then again, wasn't entirely sure that everyone was on board.
In particular, thought on-hold only applied when ready.

Member

blairconrad commented Aug 17, 2016

Ah. I should've thought of that. Then again, wasn't entirely sure that everyone was on board.
In particular, thought on-hold only applied when ready.

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Aug 17, 2016

Member

thought on-hold only applied when ready

That probably makes sense, although I'm not sure we're all on board with only bringing things into in-progress which are first ready, so it may better to apply on-hold earlier rather than later.

Member

adamralph commented Aug 17, 2016

thought on-hold only applied when ready

That probably makes sense, although I'm not sure we're all on board with only bringing things into in-progress which are first ready, so it may better to apply on-hold earlier rather than later.

@thomaslevesque

This comment has been minimized.

Show comment
Hide comment
@thomaslevesque

thomaslevesque Sep 12, 2016

Member

I hadn't realized this issue was still open. I agree with the proposed behavior.

Member

thomaslevesque commented Sep 12, 2016

I hadn't realized this issue was still open. I agree with the proposed behavior.

@blairconrad

This comment has been minimized.

Show comment
Hide comment
@blairconrad

blairconrad Sep 12, 2016

Member

Thanks, @thomaslevesque. Open because breaking. Otherwise, I'd've been on it like Garfield on lasagna.

Member

blairconrad commented Sep 12, 2016

Thanks, @thomaslevesque. Open because breaking. Otherwise, I'd've been on it like Garfield on lasagna.

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Nov 15, 2016

Member

Is this something we want to do in 3.0?

Member

adamralph commented Nov 15, 2016

Is this something we want to do in 3.0?

@blairconrad

This comment has been minimized.

Show comment
Hide comment
@blairconrad

blairconrad Nov 15, 2016

Member

It's something I'd like to do.
Unless we're in a tearing rush for 3.0, I'd try to get it in.

Member

blairconrad commented Nov 15, 2016

It's something I'd like to do.
Unless we're in a tearing rush for 3.0, I'd try to get it in.

@blairconrad

This comment has been minimized.

Show comment
Hide comment
@blairconrad

blairconrad Nov 15, 2016

Member

It's something I'd like to do.

by which I mean I think we should do it. Not claiming. Although I would do it.

Member

blairconrad commented Nov 15, 2016

It's something I'd like to do.

by which I mean I think we should do it. Not claiming. Although I would do it.

@thomaslevesque

This comment has been minimized.

Show comment
Hide comment
@thomaslevesque

thomaslevesque Nov 15, 2016

Member

I also think we should do it 👍

Member

thomaslevesque commented Nov 15, 2016

I also think we should do it 👍

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Nov 15, 2016

Member

Fine by me. Adding to 3.0.0 milestone and un-on-holding.

Member

adamralph commented Nov 15, 2016

Fine by me. Adding to 3.0.0 milestone and un-on-holding.

@blairconrad

This comment has been minimized.

Show comment
Hide comment
@blairconrad

blairconrad Nov 20, 2016

Member

Thanks for the merge!
Oh. I should update release notes. I wonder if we're going for an alpha002 or a beta001…

Member

blairconrad commented Nov 20, 2016

Thanks for the merge!
Oh. I should update release notes. I wonder if we're going for an alpha002 or a beta001…

@thomaslevesque

This comment has been minimized.

Show comment
Hide comment
@thomaslevesque

thomaslevesque Nov 20, 2016

Member

I wonder if we're going for an alpha002 or a beta001…

Well, Castle.Core 4.0.0 is beta now, so I guess we could do a beta as well, and release a final version once Castle.Core goes final too.

Member

thomaslevesque commented Nov 20, 2016

I wonder if we're going for an alpha002 or a beta001…

Well, Castle.Core 4.0.0 is beta now, so I guess we could do a beta as well, and release a final version once Castle.Core goes final too.

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Nov 20, 2016

Member

Beta generally means that no more breaking changes are planned. Given that we still have #910 on the 3.0.0 milestone, I'm not sure we can progress past alpha yet.

I'm also not sure about #904 since I haven't had a chance to catch up on the conversation there yet.

Member

adamralph commented Nov 20, 2016

Beta generally means that no more breaking changes are planned. Given that we still have #910 on the 3.0.0 milestone, I'm not sure we can progress past alpha yet.

I'm also not sure about #904 since I haven't had a chance to catch up on the conversation there yet.

@blairconrad

This comment has been minimized.

Show comment
Hide comment
@blairconrad

blairconrad Nov 20, 2016

Member

Beta generally means that no more breaking changes are planned.

Whoa. Did we not meet that goal in the lead-up to 2.0!

I guess maybe at each release we hadn't planned any breaking changes.

Member

blairconrad commented Nov 20, 2016

Beta generally means that no more breaking changes are planned.

Whoa. Did we not meet that goal in the lead-up to 2.0!

I guess maybe at each release we hadn't planned any breaking changes.

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Nov 20, 2016

Member

Yeah, I think the transition from alpha to beta is still at the mercy of breaking changes that you don't yet know you need to do, but I think that's fine.

Member

adamralph commented Nov 20, 2016

Yeah, I think the transition from alpha to beta is still at the mercy of breaking changes that you don't yet know you need to do, but I think that's fine.

@thomaslevesque

This comment has been minimized.

Show comment
Hide comment
@thomaslevesque

thomaslevesque Nov 20, 2016

Member

Beta generally means that no more breaking changes are planned

I thought that was RC?

Member

thomaslevesque commented Nov 20, 2016

Beta generally means that no more breaking changes are planned

I thought that was RC?

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Nov 20, 2016

Member

An RC is the version that will be RTM, unless someone finds a bug. I.e. RTM should ideally be built off the same commit. If you look at our current 3.0.0 milestone, after we close #910, the remaining work is deprecating self initialised fakes and adding acceptance tests for netstd, which sound like text book "remaining things to do after the beta release", before RC.

Member

adamralph commented Nov 20, 2016

An RC is the version that will be RTM, unless someone finds a bug. I.e. RTM should ideally be built off the same commit. If you look at our current 3.0.0 milestone, after we close #910, the remaining work is deprecating self initialised fakes and adding acceptance tests for netstd, which sound like text book "remaining things to do after the beta release", before RC.

@blairconrad

This comment has been minimized.

Show comment
Hide comment
@blairconrad

blairconrad Feb 22, 2017

Member

This issue has been released in FakeItEasy 3.0.0:
https://github.com/FakeItEasy/FakeItEasy/releases/3.0.0

Member

blairconrad commented Feb 22, 2017

This issue has been released in FakeItEasy 3.0.0:
https://github.com/FakeItEasy/FakeItEasy/releases/3.0.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment