-
-
Notifications
You must be signed in to change notification settings - Fork 113
Feature/navigation lock #809
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
src/bunit.web/TestDoubles/NavigationManager/FakeNavigationManager.cs
Outdated
Show resolved
Hide resolved
I'm going to get to this as soon as I get a little time to do a proper review. |
Since v1 will also support .net7 I think we need to target main. I will see about getting Codespaces set up here on github such that you can work on this. Tracking this here: dotnet-foundation/projects#218 |
nah don't worry. I still have my old beloved windows notebook. Everytime when I open something the fan goes crazy, but he still works ;) That said I will retargeted the branch to |
tests/bunit.web.tests/TestDoubles/NavigationManager/FakeNavigationManagerTest.cs
Outdated
Show resolved
Hide resolved
tests/bunit.web.tests/TestDoubles/NavigationManager/FakeNavigationManagerTest.cs
Outdated
Show resolved
Hide resolved
tests/bunit.web.tests/TestDoubles/NavigationManager/FakeNavigationManagerTest.cs
Outdated
Show resolved
Hide resolved
tests/bunit.web.tests/TestDoubles/NavigationManager/FakeNavigationManagerTest.cs
Outdated
Show resolved
Hide resolved
I think I need a bit more explanation on why this wont work with bUnit. Can you elaborate. |
OK, looks good so far. I'm still vacationing, but will see if I can get back to this again later today or tomorrow with a follow-up. Thanks for your patience. |
Ok. Let's make it visual: @inject NavigationManager NavigationManager
<a href="/counter">Go to Counter</a>
<button @onclick="@(() => NavigatioNmanager.NavgiateTo("/counter"))">Go to counter</button>
<NavigationLock OnBeforeInternalNavigation="PreventNavigation"></NavigationLock>
@code {
private void PreventNavigation(LocationChangingContext context) => context.PreventNavigation();
} Let's ignore bUnit for a second. If we have this component and open our browser, the user can click either on the button or the Back to bUnit. The public void ButtonCase()
{
var cut = RenderComponent<MyComponent>();
var button = cut.Find("button").Click();
// Assert we did not go away for example via history of NavigationManager
} But how does that work with an The work around to test the public void ACase()
{
var cut = RenderComponent<MyComponent>();
// That does the same as clicking on the <a> element
Services.GetRequiredService<NavigationManager>().NavigateTo("/counter");
// Assert we did not go away for example via history of NavigationManager
} If we are here on the same page, I can add that to the documentation, which is anyway outstanding at the moment. |
Then you should stay in vacationing mode ;) Anyway we can't merge this until somewhen in September until .net7.0 rc1 hits the public |
Co-authored-by: Egil Hansen <[email protected]>
Co-authored-by: Egil Hansen <[email protected]>
1f9bd5b
to
d315598
Compare
So I rebased onto |
We could extend our NavigationHistory here as well to include whether or not a navigation attempt was completed or cancelled. |
Do you have a specific use case in mind? From an user point of view shouldn't it be enough to have no entry? |
I think there could be cases where a test wants to see if e.g. the first attempt was blocked but not the second, and that assertion might be more clear written by looking into the history and seeing the first entry being canceled and the second not. An assertion on the number of items in the history to confirm this would not necessarily be correct, since there could be other reasons why there is no entry, e.g. the CUT didn't actually attempt a navigation. |
I get your point but still think this will create unit tests which rely on structure or implementation details rather than actual behaviour. Your use-case describes missing unit tests which cover the other cases. |
But with navigation from a component under test, the only place a user can verify the correct behavior is through the |
That is true. My point is more what should a user test? For me: Effect / Outcome. Both cases are testable with the current approach without any boilerplate code. I hope you can understand my motivation behind my questioning. |
I think I get where you are coming from. I just have feeling that there will be users who will have a weird need to write that assertion, and will request that we add that at some point, maybe they have something crazy like a timer based navigation. It would be a breaking change adding it later, so that's also a motivation for including it now. |
Then let's do it. From a design point of view I guess we will always push an entry on the |
I think we also need to actually cancel the navigation like you do in your PR here, so yeah, the flag should be something like |
Yes exactly. We could do |
You could argue the gain is that But that also seem a bit overdone, perhaps lets leave it out for now and see if users are confused. |
Yes. I like that. If we add it preemptively without need we also have to maintain that in case of changes. |
tests/bunit.web.tests/TestDoubles/NavigationManager/FakeNavigationManagerTest.cs
Show resolved
Hide resolved
I added changelog as well as docu |
Converting it to draft as it is not runnable and thus mergable yet. |
.net 7.0-rc1 is released so this PR can go live (in theory). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC this is already reviewed and looks great.
You wanna wait until we fixed the WaitFor issue to reduce noise or you don’t mind? |
This should not make a difference, so this can be merged. |
This pull requests allows the
FakeNavigationManager
to prevent navigation when aNavigationLock
component is existing. Fixes #804. At the moment this PR can not be merged as the feature is targeted for7.0.0-rc.1
which will be available September. Also I targetedv2
but maybe it makes sense to have this feature available on ourmain
branch as well. As I am mainly working on a Mac M1 I stuck to use >=net6.0. Let me know your thoughts. I am happy to targetmain
instead ofv2
.New behaviour
NavigationLock
works with ourFakeNavigationManager
. That said if user code prevents navigation, so will theFakeNavigationManager
Out of Scope
NavigationManager
itself. In theory the "wild" aka "real blazor" we can use theNavigationLock
with stuff like that:<a href="https://github.com/internal">Text</a>
and the user can prevent navigation. As we are no browser and do not have a router which would the task for us, we can't implement that. But the user can do the following in a test:Most probable we want to have this in the documentation. Still a bit of mixed feelings about that, but I can't imagine another way to guide the user here.