## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
• Aug 22 10:55
rytmis opened #67
• Feb 19 13:13
anth12 opened #66
• Jan 15 11:08
JosephWoodward edited #65
• Jan 15 11:05
JosephWoodward opened #65
• Jan 09 16:24

jeremydmiller on gh-pages

Documentation Update for 3.0.0 (compare)

• Jan 09 16:22

jeremydmiller on gh-pages

Documentation Update for 3.0.0 (compare)

• Jan 09 14:38

jeremydmiller on gh-pages

Documentation Update for 3.0.0 (compare)

• Jan 09 14:28

jeremydmiller on master

docs for 3.0, little sample fix… (compare)

• Jan 09 12:27

jeremydmiller on master

using the <TargetLatestRuntimeP… (compare)

• Jan 09 12:25

jeremydmiller on master

bumping to 3.0 (compare)

• Jan 09 12:21

jeremydmiller on master

letting the Nuget dependencies … removed all references in testi… this time SM is really gone and 3 more (compare)

• Jan 08 17:53
Pondidum commented #57
• Jan 08 14:15
jeremydmiller closed #64
• Jan 08 14:15
jeremydmiller commented #64
• Jan 08 14:15

jeremydmiller on master

Tests on Before/After methods. … bumping to Alba 2.2. Added help… (compare)

• Jan 08 14:15
jeremydmiller closed #62
• Jan 08 13:24
jeremydmiller commented #64
• Jan 08 13:22
jeremydmiller closed #63
• Jan 08 13:22
jeremydmiller commented #63
• Jan 08 13:22
jeremydmiller labeled #63
larsest1
@larsest1

Hi
I am trying to override service registrations

I have used to code from the documentation "Hosting and Other Configuration" (http://jasperfx.github.io/alba/documentation/bootstrapping/)

But it still runs ConfigureServices in startup.cs when I hit
var system = new SystemUnderTest(builder, applicationAssembly:typeof(Startup).Assembly);

How can I avid that this happens?

See my test below

TokenSettings = new GitTokenSettings();
TokenSettings.Token = "h8976879sgsd98sgag78";

Options = new Mock<IOptions<GitTokenSettings>>();
Options.Setup(git => git.Value).Returns(TokenSettings);

MockpullRequestStatusService = new Mock<IPullRequestStatusService>();
MockpullRequestStatusService.Setup((x => x.SetPullRequestStatus(String.Empty, string.Empty, string.Empty, string.Empty))).Returns((Task.FromResult(200)));

MockPullReqClient = new Mock<IPullRequestStatusClient>();
MockPullReqClient.Setup(x => x.GetOpenPullRequests("bla", "blabla")).Returns(It.IsAny<string>());

var builder = WebHost.CreateDefaultBuilder()
.UseStartup<Startup>()
.UseContentRoot(@"C:\Repos\tools-branch-status-check-service\BranchStatusCheckService")
.ConfigureServices(s => {
});

TheSystem = new SystemUnderTest(builder, applicationAssembly: typeof(Startup).Assembly);

Jeremy D. Miller
@jeremydmiller
The ConfigureServices() call will happen regardless of the usage of Startup. I honestly don’t remember the order, but I’m guessing from this question that the ConfigureServices() is called after and the overrides don’t get to apply?
larsest1
@larsest1
Yep
Jeremy D. Miller
@jeremydmiller
Ugh, okay. And I’m guessing that you want everything that the Startup does, but also to override services just in testing as well?
larsest1
@larsest1
That would be nice :)
Jeremy D. Miller
@jeremydmiller
Used to be really easy in my old FubuMVC + StructureMap combo years ago.
It is possible w/ AspNetCore hosting, but they don’t make it easy or obvious at all. You might need to let me think about this for awhile and see if there’s an easier way to expose this in a reusable API in Alba
larsest1
@larsest1
I am not that experienced with aps.net core. A colleague of mine just recommended Alba to me :)
Ok, thanks :)
Jeremy D. Miller
@jeremydmiller
Easiest thing to do is to do some conditional registration based on the HostingEnvironment, but that means either making a hard coupling from production code to testing fakes or doing something that tries to dynamically load registrations
Hmm.
larsest1
@larsest1
Found the solution!
You have to use TryAddTransient in configureServices()
Then it won't register anything, if it has already been registered.
Jeremy D. Miller
@jeremydmiller
Sure, but that doesn’t help you out with the ordering per se
Unless you mean to do that in the STartup
larsest1
@larsest1
But it does not overwrtie my mocks
Yes, doing it in startup
Jeremy D. Miller
@jeremydmiller
Then this sounds like a documentation effort now
Lauri Kotilainen
@rytmis
@jeremydmiller Hi! Do you know if anyone has taken a look at adapting Alba for ASP.NET Core 3.0? There seems to be at least one rather major obstacle, which is that TestServer will now forcibly replace the Response Body stream with an implementation that doesn't allow for seeking -- this happens regardless of whether one uses an earlier phase of the pipeline to stick in e.g. a MemoryStream.
Jeremy D. Miller
@jeremydmiller
Not that I know of yet if you’re volunteering;) It’s hopefully less churn than it was going from 1 to 2 this time.
Lauri Kotilainen
@rytmis
Haha. Ahahaha.
See, the thing is, now that they're moving to a monorepo model, the NuGet packages that had the word "Internal" in them are in fact going to become internal.
Most of that seems to have only minor effects. But the TestServer changes might actually hurt. I'm trying to bother David Fowler about this over at the aspnetcore slack.
Lauri Kotilainen
@rytmis
On that note, what are your thoughts about versioning this time around? Should I assume that netcoreapp3.0 means ASP.NET Core 3.0? It's either that or yet another separate package, I guess.
Jeremy D. Miller
@jeremydmiller
I’d like to try to multi-target this time. Even knowing that means some conditional compilation.
Lauri Kotilainen
@rytmis
I thought as much.
Jeremy D. Miller
@jeremydmiller
How close is 3.0 to hitting?
Lauri Kotilainen
@rytmis
It's RC with a Go-live license with a commitment to avoid API breakage from now on.
Jeremy D. Miller
@jeremydmiller
Lauri Kotilainen
@rytmis

The new TestServer usage pattern is to use a sort of builder to construct it and then it provides you with a HttpClient that will dispatch the request, so you get the ResponseMessage with its assorted things. Most of the APIs Alba uses are still available -- I've got some initial work with conditional compilation locally. It's the response body that's giving me headache right now.

I should probably look more closely into the TestServer APIs at some point to see if there are other ways of going about this.

Well, I shouldn't say new because for all I know, it could have been that to begin with.
Jeremy D. Miller
@jeremydmiller
You can always cheat and wrap middleware around the normal stack that substitutes out the response body w/ a MemoryStream
Lauri Kotilainen
@rytmis
Nope. I tried that.
Jeremy D. Miller
@jeremydmiller
Why wouldn’t that work?
Lauri Kotilainen
@rytmis
Just a sec, I'll look it up.
Here, I'm in TestServer.SendAsync, and the httpContext has the MemoryStream as a Body that I've set up:
Jeremy D. Miller
@jeremydmiller
So their theory of how everything is going to work now is to use HttpClient for everything?
Lauri Kotilainen
@rytmis
This is further down the stack when TestServer begins to return the response:
The ResponseBodyReaderStream is what we see when looking at the response.
Jeremy D. Miller
@jeremydmiller
Okay. Might not be a killer, but the ResponseBody stuff may need to be smarter. Maybe we buffer that on the way back out
Lauri Kotilainen
@rytmis
Yeah. The problem I'm currently looking at is, because of this TestServer behavior, I haven't yet found any way to read the response body from within the HttpContext.
There has got to be something I'm missing here, though. There's no way this is intentional: this would mean that production code that assumes it can replace the Body stream won't work under TestServer either. 🤔
Jeremy D. Miller
@jeremydmiller
Gotcha. Could we have Alba run the request, then replace the response body with a stream that copies (lazily) the content from the stream we get from the HttpClient invocation?
Lauri Kotilainen
@rytmis
Don't know yet. I should probably play around with a plain TestServer to get a handle on how it's meant to be used.
Lauri Kotilainen
@rytmis
Welp, it turns out that the correct thing to do is to not replace the response stream (which is what Alba already did). By letting TestServer keep its own response stream, the resulting ResponseBodyReaderStream actually contains the output.
I still don't quite see how this would work out with a middleware that actually needs to modify the output, but maybe I'm missing something.
Lauri Kotilainen
@rytmis
And with that realization, I'm down to 36 failing tests on Core 3.0.