Skip to content

Add default JsRuntime #32

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

Merged
merged 11 commits into from
Jan 22, 2020
Merged

Add default JsRuntime #32

merged 11 commits into from
Jan 22, 2020

Conversation

Siphonophora
Copy link
Contributor

Hi. This should resolve #26.

@egil egil self-requested a review January 13, 2020 08:56
@egil
Copy link
Member

egil commented Jan 13, 2020

Hi @Siphonophora, thanks for this. I really appreciate you spending your time on this.

I will look over the code and review on Wednesday. I am busy these days preparing for .net conf tomorrow, so time is limited.

@Siphonophora
Copy link
Contributor Author

@egil sounds good. I saw the promo for .net conf the other day, which is actually what reminded me that i wanted to check out this project.

@egil
Copy link
Member

egil commented Jan 15, 2020

Hi @Siphonophora,

I just took a quick look through your code. When I originally added the related issue, my thought was simply to have a placeholder class, that when instantiated by the DI container, would throw an exception with a helpful exception message. My thinking was that it would stop a test as soon as a component was being rendered the first time.

Now I am thinking that maybe your approach is better, since it will allow components with a jsruntime dependency to be rendered and tested, as long as the logic being tested doesn't involve calling the jsruntime.

Was this something you considered?

using System.Threading.Tasks;
using Microsoft.JSInterop;

[assembly: InternalsVisibleTo("Egil.RazorComponents.Testing.Library.Tests")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets move this to an Assembly.cs file at the root of the project.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

/// <summary>
/// This JsRuntime is used to provide users with helpful exceptions if they fail to provide a mock when required.
/// </summary>
internal class DefaultJsRuntime : IJSRuntime
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I know I used the word "default" in the issue related to this, but I do not think default is the right word here. We need a word that indicates that this JsRuntime is actually not usable, and just a placeholder for something else that implements IJSRuntime.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will think about naming more. At least since its internal the users won't be confused.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about placeholder?

I noticed I started using that word in the comments,

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds good, should be clear its not a real version.

Comment on lines 24 to 28
var ex = new Exception(MissingJsRuntimeMessage);
ex.HelpLink = MissingJsRuntimeHelpLink;
ex.Data.Add("identifier", identifier);
ex.Data.Add("args", args);
throw ex;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very good idea to use the HelpLink property in exceptions to point to the wiki.

However, all of this needs to be moved to its own custom exception type, such that the InvokeAsync methods simply throw that.

Question: what was your thinking around passing args to the exception? Do you think it will be usable to the users?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can add a new type.

I was thinking that someone who didn't expect their test to invoke any JS might be aided if we provided everything we know about the invocation. Maybe its low value, but it was easy so I threw it in.

Still, when I was trying to debug into this to see the args, I ran into issues because of the aggregate exception logic. If users are going to have this issue, I would probably just move the identifier into the exception message.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think adding the identifier to exception message is a good idea.

Also, in the custom exception, you can simply add properties for the identifier and args, such that they are easily accessible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@Siphonophora
Copy link
Contributor Author

Hi @egil,

I thought this style of implementation was what you were thinking about, so I didn't look at throwing exceptions whenever the @inject IJSRuntime is present. Personally I would prefer the option where I only have to supply the mock if it is used, just because it will make the tests a little cleaner.

I should be able to make changes this weekend.

@egil
Copy link
Member

egil commented Jan 16, 2020

Great, thanks. I like your solution better too.

Btw. change your merge target to the DEV branch please.

@Siphonophora Siphonophora changed the base branch from master to dev January 20, 2020 16:43
@Siphonophora
Copy link
Contributor Author

@egil This should be all set.

@egil
Copy link
Member

egil commented Jan 20, 2020

Thanks. I'll take a look later tonight or tomorrow morning.

Copy link
Member

@egil egil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi again Michael

Thanks for the effort. I have a few small changes I would like, but you should be able to apply them directly from GitHub except one.

When they are out of the way, ill merge your PR.

Thanks again.

Comment on lines 42 to 45
private static string PrintArguments(IReadOnlyList<object> arguments)
{
return string.Join(", ", arguments.Select(x => x.ToString()));
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed this.

@egil egil merged commit 7411c68 into bUnit-dev:dev Jan 22, 2020
@Siphonophora Siphonophora deleted the Add-default-jsruntime branch January 22, 2020 14:46
egil added a commit that referenced this pull request Jan 22, 2020
* Fixed spelling mistake in comment

* Reordered parameters to top of TestRenderer

* Add support for asynchronous Razor tests (#27)

* Add support for asyncrhonous Razor tests

* Rename Fixture.AsyncTest to TestAsync

* Update description of Fixture

Co-Authored-By: Egil Hansen <[email protected]>

* Dotnetconf samples (#33)

* Basic example tests

* Add missing MarkupMatches overload

* Added docs to MockHttp extensions

* dotnet conf samples

* Added unit tests of CompareTo, Generic and Collection assert extensions.

* Added tests for general events and touch events dispatch extensions

* Added tests for anglesharp extensions, JsRuntimeInvocation and ComponentParameter

* Removed assert helpers that conflict with Shoudly

* Tests of JsRuntimeAsserts

* Reorganized test library

* Suppressing warnings in sample

* Changed ITestContext to have a CreateNodes method instead of HtmlParser property

* Removed empty test

* Added missing code documentation

* Moved MockJsRuntime to its own namespace

* Pulled sample from main solution into own solution

* Update main.yml

* Change GetNodes and GetMarkup to Nodes and Markup properties in IRenderedFragment (#34)

* Add SetupVoid and SetVoidResult capabilities to JsRuntime mock (#35)

* Moved MockJsRuntime to its own namespace

* Add SetupVoid() and SetVoidResult() to PlannedInvocation and Mock

* Updates to template and sample

* Add default JsRuntime (#32)

* Add default JsRuntime

* Update src/Mocking/JSInterop/DefaultJsRuntime.cs

Co-Authored-By: Egil Hansen <[email protected]>

* Response to review. Add custom exception and code cleanup

* Remove unneded method

* Update src/Mocking/JSInterop/MissingMockJsRuntimeException.cs

Co-Authored-By: Egil Hansen <[email protected]>

* Update src/Mocking/JSInterop/MissingMockJsRuntimeException.cs

Co-Authored-By: Egil Hansen <[email protected]>

* Update src/Mocking/JSInterop/MissingMockJsRuntimeException.cs

Co-Authored-By: Egil Hansen <[email protected]>

* Update src/Mocking/JSInterop/MissingMockJsRuntimeException.cs

Co-Authored-By: Egil Hansen <[email protected]>

* Update src/Mocking/JSInterop/MissingMockJsRuntimeException.cs

Co-Authored-By: Egil Hansen <[email protected]>

* Update src/Mocking/JSInterop/MissingMockJsRuntimeException.cs

Co-Authored-By: Egil Hansen <[email protected]>

Co-authored-by: Egil Hansen <[email protected]>

* Add .vscode to gitignore

* TestServiceProvider now explictly implements IServiceCOlelction (#40)

* TestServiceProvider now explictly implements IServiceCOlelction

* Tweaks to namespaces

* Added async setup method to snapshot test

* Added test of SnapshotTests use of setup methods

* Update to readme

* Removed duplicated MarkupMatches method

* Removed PR trigger

Co-authored-by: Rastislav Novotný <[email protected]>
Co-authored-by: Michael J Conrad <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants