by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 01 2016 16:24
    jeremymeng synchronize #617
  • Apr 01 2016 14:28
    blairconrad commented #490
  • Apr 01 2016 11:07
    blairconrad commented #629
  • Mar 31 2016 14:14
    PascalK starred FakeItEasy/FakeItEasy
  • Mar 31 2016 13:00
    blairconrad commented #490
  • Mar 31 2016 12:48
    drauch commented #490
  • Mar 31 2016 10:57
    blairconrad commented #617
  • Mar 31 2016 10:52
    adamralph commented #617
  • Mar 31 2016 10:42
    blairconrad commented #617
  • Mar 31 2016 10:41
    blairconrad commented #617
  • Mar 31 2016 10:29
    adamralph commented #617
  • Mar 31 2016 09:27
    adamralph commented #637
  • Mar 31 2016 08:29
    cecilphillip commented #637
  • Mar 31 2016 06:27
    M-Zuber commented #637
  • Mar 31 2016 06:25
    thecodejunkie commented #637
  • Mar 31 2016 06:25
    adamralph commented #637
  • Mar 31 2016 06:24
    adamralph commented #637
  • Mar 31 2016 06:13
    adamralph labeled #637
  • Mar 31 2016 06:13
    adamralph labeled #637
  • Mar 31 2016 06:13
    adamralph assigned #637
Luke Marlin
@LukeMarlin
Anyway, I'll give a try to exposing next week it as you mentioned
Thomas Levesque
@thomaslevesque
Yes, it is. The interface is public, but its implementations are all private, and there's no easily way to access them (you can only get them via the FakeManager when you configured a call)
What bothers me is that this interface doesn't just encapsulate which calls should be matched, but also how these calls should behave
Luke Marlin
@LukeMarlin
Maybe it's possible to expose a restricted version of it?
With a new interface. It's not like one more is going to be too much at that point :D
Thomas Levesque
@thomaslevesque
Maybe we should split it into 2 different interfaces, one to specify what is matched, and one to specify how it behaves.
Anyway, it would be a significant refactoring, I think.
Not something to undertake lightly
Blair Conrad
@blairconrad

What bothers me is that this interface doesn't just encapsulate which calls should be matched, but also how these calls should behave

Yeah, I was tracking down the interfaces we return from the various A.CallTo and A.CallToSets (and extensions such as WithAnyArguments and To) and wondering if we could provide a very narrow interface that's all about the call validation.

it would be a significant refactoring, I think.

Well, we are about to break things anyhow. Then again, we'd need to look at the scope of the breakage and balance it against the utility of the feature.

And now I'm wondering about Fake<T>.CallsTo!
Thomas Levesque
@thomaslevesque
Another issue, currently, is that call rules are mutable. What is called BuildableCallRule is really MutableCallRule. If we introduce something like AsRule() like in my example above, the rule that is returned should really be a snapshot of the state of the rule when AsRule() is called. Otherwise, we could have things like this:
var callToConfigure = A.CallTo(() => fake.Foo());
var rule = call.AsRule();
callToConfigure.Where(... ) // rule modified here
    .Returns(42);
Blair Conrad
@blairconrad
I guess it returns the same set of interfaces, so...
Yeah, and I don't love AsRule to begin with. I'd rather have immutable rules inside.
Thomas Levesque
@thomaslevesque

I'd rather have immutable rules inside.

Me too. If they were immutable, each call to a configuration method would return a new instance. And it could directly implement IFakeObjectRule (or at least a new interface that exposes IsApplicableTo)

And it could directly implement IFakeObjectRule (or at least a new interface that exposes IsApplicableTo)

Or maybe not, because then IsApplicableTo would show up in Intellisense for configuration interfaces, which would be messy

Blair Conrad
@blairconrad
Hide it like we do with IHideObjectMembers?
I know, doesn't hide it for all...
Thomas Levesque
@thomaslevesque
(sorry if this is all a little confusing, I'm thinking as I type...)
Blair Conrad
@blairconrad
(Me too.)
Thomas Levesque
@thomaslevesque
Anyway, I think we should formalize (as an interface) what constitutes a "call specification", i.e. what calls should be matched, and make that immutable. This interface would provide a way to match a call. And the "behavior" methods (Returns, Throws, etc) would work with that.
It would make the whole configuration API easier to think about, I think.
Blair Conrad
@blairconrad
Oh, do you find it difficult now?
:stuck_out_tongue_winking_eye:
Thomas Levesque
@thomaslevesque
I always did!
Blair Conrad
@blairconrad
It breaks my head!
Yeah, even when it was "easy", it was hard.
Recent additions like property setters and ordered calls did not help.
Thomas Levesque
@thomaslevesque
Anyway, the existing configuration interfaces wouldn't disappear. They're still needed for fluent configuration. It's just that we would have a common base interface to represent "which calls are matched"
Blair Conrad
@blairconrad
Thomas Levesque
@thomaslevesque
Blair Conrad
@blairconrad
Blair Conrad
@blairconrad
New production release of FakeItEasy! 6.0.0
https://twitter.com/fakeiteasyfx/status/1218140938654142466
Thomas Levesque
@thomaslevesque
Alper
@asunar
Is there any guidance on when to use the AutoFake.Dispose method? When working with objects implementing IDisposable?
Thomas Levesque
@thomaslevesque
Hi @asunar, I'm not sure what you're referring to... there's nothing called AutoFake in FakeItEasy
Alper
@asunar
I meant an instance of AutoFake.
Thomas Levesque
@thomaslevesque
Using the Autofac.Extras.FakeItEasy package?
Alper
@asunar
private readonly AutoFake _faker;
// later
 _faker?.Dispose();
Thomas Levesque
@thomaslevesque
We don't maintain this, it's made by the AutoFac folks
Alper
@asunar
oops yes, sorry. Looks like it's in Autofac.Extras.FakeItEasy
Thomas Levesque
@thomaslevesque
You should probably ask in this repo: https://github.com/autofac/Autofac.Extras.FakeItEasy
Alper
@asunar
Thank you.
Thomas Levesque
@thomaslevesque
Or in their Gitter, if they have one
Alper
@asunar
Awesome, thanks.
Blair Conrad
@blairconrad
Sadly, they kind of don't maintain it either. It's a contributed repo, and neither Autofac nor FakeItEasy know enough about it to be really responsible…
Hi, @asunar.
Alper
@asunar
Hello, @blairconrad thanks for the info.
Blair Conrad
@blairconrad
At a guess, though, I'd probably never call it. Just make a new AutoFake for each test and throw 'em away when done. They'll clean themselves up eventually.