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
TreeHappy
@TreeHappy
Because it is all in the same AppDomain context FakeItEasy will never reevaluate the RootModule etc. It would be really cool to be able to get a way to reevaluate this or (logical) to be able to not use a singleton for the root module.
Why this works in VS with the Xunit test adapter i do not know for sure. My suspicion is that it works because it also passes single assemblies to the testadapter and then this problem does not arise.
One last thing i would be a great fan of beeing able to pass loaded Assemblies to the Bootstrapper instead of strings. That way i can deal with all the AppDomain resolve stuff on my side. And in my case i already have all the Assemblies loaded. Plus this way i was able to also generate assemblies later on and pass them to the TypeCatalogue etc.
Thomas Levesque
@thomaslevesque
Ouch. Nice job identifying the issue, that was definitely not straightforward.

One last thing i would be a great fan of beeing able to pass loaded Assemblies to the Bootstrapper instead of strings.

Yeah, this API always struck me as less than ideal... Changing it now would be a breaking change, but not a blocking one; not that many people use a bootstrapper anyway.

Regarding your suggestion to specify the dummy factories explicitly, I think it has merit. On the other hand, in the 12 years FakeItEasy has existed, it's the first time someone needs it, so it would be a very niche feature. We probably need to discuss it further to refine the idea anyway.
TreeHappy
@TreeHappy
Sure, i think that this problem should arise more often the more you try to work with native resources / dlls etc.
If Xunit changes how they work with assemblies in VS i am out of luck again.
Maybe it would be enough to have some kind of function i can call to flag that the next time it tries to use the root model it should rebuild stuff or so.
Then i could work that into my teardown (in nunit) / dispose (in xunit)
Thomas Levesque
@thomaslevesque
Have you tried tweaking the xunit runner configuration?
https://xunit.net/docs/configuration-files
There's an appDomain setting that could be related to your problem
Maybe parallelizeAssembly could help too
TreeHappy
@TreeHappy
The thing is that exactly the ability to not run app domains is why i switch to xunit.
Thomas Levesque
@thomaslevesque
ok
TreeHappy
@TreeHappy
As i stated the problem is that when you work with app domains dlls get loaded in the main app domain
and i can not get rid of them. At least how we work with them. I wish we would to it differently but that might go beyond the scope of the discussion.
I can elaborate on the point if you want.
But we need to be able to not use app domains in the testing context.
So when the second assembly gets run, since i am still in the same app domain the root model does not get build.
Thomas Levesque
@thomaslevesque
I guess you can always run the test assemblies separately... not ideal, but it should fix the problem.
TreeHappy
@TreeHappy
True that is what i do in the command line atm. But i am at the mercy of xunit and Vs when we want to run tests there.
Thomas Levesque
@thomaslevesque
yeah...
TreeHappy
@TreeHappy
Personally i am not a fan of all this static stuff any way to be honest. So i would really appreciate if FakeItEasy would have the ability to work with an explicit context. I can see the point though of breaking changes etc.
It is really a pain to work with this project reguarding all this :) it is really complex.
Also i am very angsty about switching to the latest .net platform :) since the app domain is kicked out etc.
It would be interesting though to maybe try out this with the latest .net platform with providing multiple assemblies to the command line runner and no app domain and app domain switched on. From what i know there is no app domain any longer and the problem might arise there also.
Thomas Levesque
@thomaslevesque

Personally i am not a fan of all this static stuff any way to be honest. So i would really appreciate if FakeItEasy would have the ability to work with an explicit context. I can see the point though of breaking changes etc.

Yes, I see your point. I generally prefer this too. But this would be a huge rework of the whole library, so I don't see it happening any time soon.
If we ever do this, we would also need to keep supporting the existing API (maybe using a default context), so that current users don't need to rewrite all their tests.

TreeHappy
@TreeHappy
If you should decide to think of changing some stuff i would be willing so test the stuff out and also would be willing to make some suggestions.
Thomas Levesque
@thomaslevesque
:+1:

What I imagine is something like this:

// create a new fake context
var context = new FakeContext();

// register all extension points from specified assembly
context.RegisterExtensions(assemblies);
// or manually register dummy factories
context.RegisterDummyFactory(typeof(MyFactory));

// create a fake using this context
var fake = A.Fake<ISomething>(context);

The rest of the API would be mostly unchanged. If you don't specify a context, it uses the default context (which works as currently, by implicitly scanning the extension points in loaded assemblies)

TreeHappy
@TreeHappy
Yes i agree to your assesment. One thing i was considering was to use A.Fake(options => options.WithContext(.... also or something like another entry point like, InContext(context).A.Fake...
Since from what i gathered so far the root model is internal and noone should dabble with it nothing of adding this should introduce braking changes.
TreeHappy
@TreeHappy
Is the verdict still out on wheather or not this might be added or is this topic concluded?
Thomas Levesque
@thomaslevesque
We didn't have a chance to discuss it yet
But to be honest, don't get your hopes up about this. It would be a major undertaking, for very little benefit (I realize that for you, it would be a big benefit, but in the 12 years FakeItEasy has been around, it's the first time someone asks for this, so it must be pretty niche)
TreeHappy
@TreeHappy
Ok just let me know what the verdict is then in the end :) i have set up the interim solution for now. Depending on what the verdict is i will check in or postpone committing my working branch.
Totally understand it. Maybe you would like to check this though for the current situation in .net. Since there is no app domain any longer.
Thomas Levesque
@thomaslevesque
I'd say commit now; assuming it happens, it will take a while.
TreeHappy
@TreeHappy
Not sure how it will behave there atm.
KK
Thanks for the fast response though :) it is really cool that the project is actively supported.
Thomas Levesque
@thomaslevesque
Well, to be honest, supporting it doesn't give us much work these days. It's mostly "done"; we've added most of the features we wanted, and there are no major outstanding bugs. The remaining ones are ones we can't really fix for one reason or another (e.g. dependent on a fix in Castle.Core or even in .NET itself).
TreeHappy
@TreeHappy
Sure still it is nice to get a quick response :)
Jokūbas
@frizjr:matrix.org
[m]

Hello, I would appreciate any input on the best approach to create dummy/fake IFormFile instance. More specifically, my controller method accepts an .xlsx/.xls/.csv document as a [FromBody] argument.

private IFormFile _formFile;
[SetUp]
public Task Setup()
{
    _formFile = A.Fake<IFormFile>();
    return Task.CompletedTask;
}

And then in my test:

// Arrange  
... 
var sut = new LtCustomersController(arguments); 
// Act  
var result = await sut.ImportLtCustomers(4, _formFile);
Blair Conrad
@blairconrad
Hi, @frizjr:matrix.org. I'm afraid we're going to need more information here. In your first snippet, _formFile = A.Fake<IFormFile>(); looks like a perfectly acceptable way to create a fake IFormFile. Are you encountering some difficulty with it?
You said "dummy/fake" in your question. Are you wondering which you should use?
And I'm not sure it'll be relevant, but just in case, is IFormFile a Microsoft.AspNetCore.Http.IFormFile?
Thomas Levesque
@thomaslevesque
Hi @frizjr:matrix.org, I think you just need to configure the fake. For the content, you could use an in-memory stream, or a real file on disk:
A.CallTo(() => _formFile.FileName).Returns("somefile.xlsx");
A.CallTo(() => _formFile.OpenReadStream()).ReturnsLazily(() => File.OpenRead("some-actual-file-on-disk.xlsx"));
Jokūbas
@frizjr:matrix.org
[m]
Yes, sorry, I got taken away from finishing my question. I was wondering on how best to configure the fake. Thank you for your quick response