You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the easiest ways to contribute is to participate in discussions on GitHub issues. You can also contribute by submitting pull requests with code changes.
4
5
5
-
## General feedback and discussions?
6
-
Start a discussion on the [issues list](https://github.com/egil/bunit/issues). Be sure to use the right template.
6
+
## General Feedback and Discussions
7
+
Start a discussion on the [bUnit discussion list](https://github.com/egil/bUnit/discussions).
7
8
8
-
## Bugs and feature requests?
9
+
## Bugs and feature requests
9
10
For bugs or feature requests, log a new issue on the [issues list](https://github.com/egil/bunit/issues). Be sure to use the right template.
10
11
11
-
## Contributing code and content
12
+
## Contributing Code and Content
12
13
13
-
bUnit accept fixes and features! Here is what you should do when writing code for bUnit:
14
+
bUnit accepts fixes and features. Here is what you should do when writing code for bUnit:
14
15
15
-
- Follow the coding conventions used in the project. In general, they align with the AspNetCore teams [coding guidelines](https://github.com/dotnet/aspnetcore/wiki/Engineering-guidelines#coding-guidelines).
16
+
- Follow the coding conventions used throughout the bUnit project. In general, they align with the AspNetCore teams [coding guidelines](https://github.com/dotnet/aspnetcore/wiki/Engineering-guidelines#coding-guidelines).
16
17
- Add, remove, or delete unit tests to cover your changes. Make sure tests are specific to the changes you are making. Tests need to be provided for every bug/feature that is completed.
17
18
- All code changes should be done on the `DEV` branch, and pull requests should target it.
18
-
- All updates to the documentation, located under `./docs/` should be done on the `main` branch **if** they are general in nature and not tied to a specific version. Changes to the documentation related to changes on the `DEV` branch should be submitted to the `DEV` branch.
19
+
- All updates to the documentation located under `./docs/` should be done on the `main` branch **if** they are general in nature and not tied to a specific version. Changes to the documentation related to changes on the `DEV` branch should be submitted to the `DEV` branch.
19
20
- Any code or documentation you share with the bUnit projects should fall under the projects license agreement.
20
21
21
-
Here are some resources to help you get started on how to contribute code or new content.
22
+
Here are some resources to help you get started on how to contribute code or new content:
22
23
23
-
*["Help wanted" issues](https://github.com/egil/bunit/labels/help%20wanted) - these issues are up for grabs. Comment on an issue if you want to create a fix.
24
-
*["Good first issue" issues](https://github.com/egil/bunit/labels/good%20first%20issue) - these are a good for newcomers.
24
+
*["Help wanted" issues](https://github.com/egil/bunit/labels/help%20wanted) - these issues are up for grabs if you want to create a fix. To do this, simply comment on the issue you want to fix.
25
+
*["Good first issue" issues](https://github.com/egil/bunit/labels/good%20first%20issue) - these are good for newcomers. Good first issues are small, usually require just a few hours of work, and do not require a deep technical knowledge of bUnit. This is a good place to start if you want to become familiar with bUnit’s inner workings and maybe take on bigger issues later.
25
26
26
-
### Identifying the scale
27
+
### Identifying the Scale of a Contribution
27
28
28
-
If you would like to contribute to one of our repositories, first identify the scale of what you would like to contribute. If it is small (grammar/spelling or a bug fix) feel free to start working on a fix. If you are submitting a feature or substantial code contribution, please discuss it with the us first.
29
+
If you would like to contribute to bUnit, first identify the scale of what you would like to contribute. If it is small (grammar/spelling or a bug fix), feel free to start working on a fix. If you are submitting a feature or substantial code contribution, please discuss it with us first.
29
30
30
-
You might also read these two blogs posts on contributing code: [Open Source Contribution Etiquette](http://tirania.org/blog/archive/2010/Dec-31.html) by Miguel de Icaza and [Don't "Push" Your Pull Requests](https://www.igvita.com/2011/12/19/dont-push-your-pull-requests/) by Ilya Grigorik.
31
+
You might also read these two blogs posts on contributing code: [Open Source Contribution Etiquette](http://tirania.org/blog/archive/2010/Dec-31.html) by Miguel de Icaza and [Don't "Push" Your Pull Requests](https://www.igvita.com/2011/12/19/dont-push-your-pull-requests/) by Ilya Grigorik. These blog posts highlight good open source collaboration etiquette and help align expectations between you and us.
31
32
32
-
All code submissions will be rigorously reviewed and tested, and only those that meet an high bar for both quality and design/roadmap appropriateness will be merged into the source.
33
+
All code submissions will be rigorously reviewed and tested, and only those that meet a high bar for both quality and design/roadmap appropriateness will be merged into the source.
33
34
34
-
### Submitting a pull request
35
+
### Submitting a Pull Request
35
36
36
-
If you don't know what a pull request is read this article: https://help.github.com/articles/using-pull-requests. Make sure the repository can build and all tests pass. Familiarize yourself with the project workflow and our coding conventions.
37
+
If you don't know what a pull request is, read this article: https://help.github.com/articles/using-pull-requests. Make sure the repository can build and all tests pass. It is also a good idea to familiarize yourself with the project workflow and our coding conventions.
Copy file name to clipboardExpand all lines: README.md
+15-16Lines changed: 15 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,36 +9,35 @@
9
9
10
10
*Sponsored message: Telerik UI for Blazor – Get 50+ native Blazor UI components to build high-performing web apps. [Give it a try](https://www.telerik.com/campaigns/blazor/free-trial-1?utm_source=egilhansen&utm_medium=cpm&utm_campaign=blazor-trial-readme-sponsored-message).*
11
11
12
-
**bUnit** is a testing library for Blazor Components. Its goal is to make it easy to write _comprehensive, stable unit tests_. You can:
12
+
**bUnit** is a testing library for Blazor Components. Its goal is to make it easy to write _comprehensive, stable unit tests_. With bUnit, you can:
13
13
14
14
- Setup and define components under tests using C# or Razor syntax
15
15
- Verify outcome using semantic HTML comparer
16
-
- Interact with and inspect components, trigger event handlers
16
+
- Interact with and inspect components as well as triggering event handlers
17
17
- Pass parameters, cascading values and inject services into components under test
18
18
- Mock `IJsRuntime` and Blazors authentication and authorization
19
19
- Perform snapshot testing
20
20
21
-
bUnit builds on top of existing unit testing frameworks such as xUnit, NUnit, and MSTest, which runs the Blazor components tests, just as any normal unit test.
21
+
bUnit builds on top of existing unit testing frameworks such as xUnit, NUnit, and MSTest, which runs the Blazor components tests just as any normal unit test.
22
22
23
23
**Go to [bUnit.egilhansen.com](https://bunit.egilhansen.com) to learn more.**
24
24
25
-
### NuGet downloads
25
+
### NuGet Downloads
26
26
27
27
bUnit is available on NuGet in various incarnations. If you are using xUnit as your general purpose testing framework, you can use `bunit`, which includes everything in one package. If you want to use NUnit or MStest, then pick `bunit.core` and `bunit.web`:
28
28
29
-
| Name |Type| NuGet Download Link |
29
+
| Name |Description| NuGet Download Link |
30
30
| ----- | ----- | ---- |
31
-
| bUnit | Library, includes core, web, and xUnit support |[](https://www.nuget.org/packages/bunit/)|
32
-
| bUnit.core | Library, only core |[](https://www.nuget.org/packages/bunit.core/)|
33
-
| bUnit.web | Library, web and core |[](https://www.nuget.org/packages/bunit.web/)|
34
-
| bUnit.xUnit | Library, xUnit and core |[](https://www.nuget.org/packages/bunit.xunit/)|
31
+
| bUnit.web | Adds support for testing Blazor components for the web. This includes bUnit.core. |[](https://www.nuget.org/packages/bunit.web/)|
32
+
| bUnit.xUnit | Adds additional support for using bUnit with xUnit, including support for Razor-based tests. |[](https://www.nuget.org/packages/bunit.xunit/)|
33
+
| bUnit.core | Core library that enables rendering a Blazor component in a test context. |[](https://www.nuget.org/packages/bunit.core/)|
35
34
| bUnit.template | Template, which currently creates an xUnit based bUnit test projects only |[](https://www.nuget.org/packages/bunit.template/)|
36
35
37
36
To get started, head to the [getting started documentation](https://bunit.egilhansen.com/docs/getting-started) to learn more.
38
37
39
38
## Sponsors
40
39
41
-
A hugh thank you to the [sponsors of my work with bUnit](https://github.com/sponsors/egil). The higher tier sponsors are:
40
+
A huge thank you to the [sponsors of my work with bUnit](https://github.com/sponsors/egil). The higher tier sponsors are:
42
41
43
42
<table>
44
43
<tr>
@@ -55,13 +54,13 @@ A hugh thank you to the [sponsors of my work with bUnit](https://github.com/spon
55
54
56
55
These are the current goals that should be reached before v1.0.0 is ready:
57
56
58
-
-**Stabilize the APIs**, such that they work equally well with both xUnit, NUnit, and MSTest as the underlying test framework. The general goals is to make it easy and obvious for developers to create the tests they needed, and fall into the pit of success.
59
-
-**Get the Razor-based testing to stable**, e.g. make the discovery and running of tests defined in .razor files stable and efficient. This includes adding support for NUnit and MSTest as test runners.
60
-
-**Improve the documentation**. Currently there are a list of "How to" guides planned in the [Update Docs](https://github.com/egil/bunit/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22updated+docs%22) milestone.
61
-
-**Join the .NET Foundation.**. This project is too large for one person to be the owner and be the sole maintainer of, so the plan is to apply for membership as soon as possible, most likely close to or after v1.0.0 ships, and get the needed support and guidance to ensure the project long term.
57
+
-**Stabilize the APIs**, such that they work equally well with both xUnit, NUnit, and MSTest as the underlying test framework. The general goals are to make it easy for developers to create the tests they need, and to fall into the pit of success.
58
+
-**Get the Razor-based testing to be stable**, e.g. make the discovery and running of tests defined in .razor files stable and efficient. This includes adding support for NUnit and MSTest as test runners.
59
+
-**Improve the documentation**. It’s a good idea to get an experienced technical editor to review the documentation, making sure it is clear and understandable. In addition to this, more ‘How to’ guides are planned in the [Update Docs](https://github.com/egil/bunit/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22updated+docs%22) milestone.
60
+
-**Join the .NET Foundation.**. This project is too large for one person to be the owner and the sole maintainer, so the plan is to apply for membership as soon as possible - most likely close to or after v1.0.0 ships - and to get the required support and guidance to ensure the project long term.
62
61
63
-
In the postv1.0.0 to v1.0.x time frame, focus will be on improving performance. Especially the spin-up time of about one second would be nice to get reduced.
62
+
In the post-v1.0.0 to v1.0.x time frame, focus will be on improving performance. In particular, it would be nice to reduce the spin-up time of about one second.
64
63
65
64
## Contributors
66
65
67
-
Shout outs and a big thank you [to all the contributors](https://github.com/egil/bunit/graphs/contributors) to the library, both including those that raise issues, provide input to issues, and those who send pull requests. Thank you!
66
+
Shout outs and a big thank you [to all the contributors](https://github.com/egil/bunit/graphs/contributors) to the library, including those that raise issues, provide input to issues, and those who send pull requests. Thank you!
This folder contains the documentation site for bUnit.
4
4
5
-
Here is a small getting started guide for contributing to the documentation.
5
+
Here is a small getting started guide for contributing to the documentation...
6
6
7
7
## Structure
8
8
9
9
1. The `site` folder contains the code for generating the documentation site, _and_ the documentation in markdown files, located in `site/docs`.
10
10
2. The `samples` folder projects for the sample code that is displayed in the documentation. It has the following projects:
11
11
-`samples/components`: A Blazor component library project where components under test are placed.
12
-
-`samples/tests/mstest`: A MSTest project, where MSTest test samples are placed.
13
-
-`samples/tests/nunit`: A NUnit project, where NUnit test samples are placed.
14
-
-`samples/tests/razor`: A xUnit based test project, where razor test samples are placed.
15
-
-`samples/tests/xunit`: A xUnit project, where xUnit C# only test samples are placed.
12
+
-`samples/tests/mstest`: A MSTest project where MSTest test samples are placed.
13
+
-`samples/tests/nunit`: A NUnit project where NUnit test samples are placed.
14
+
-`samples/tests/razor`: A xUnit based test project where razor test samples are placed.
15
+
-`samples/tests/xunit`: A xUnit project where xUnit C# only test samples are placed.
16
16
17
-
These samples components source files and tests source files are included in the documentation using [DocFx's Code Snippet syntax](https://dotnet.github.io/docfx/spec/docfx_flavored_markdown.html?tabs=tabid-1%2Ctabid-a#code-snippet). They are created as real projects, making them runnable, which helps ensure that the code shown in the documentation pages are correct and works.
17
+
These sample components source files and tests source files are included in the documentation using [DocFx's Code Snippet syntax](https://dotnet.github.io/docfx/spec/docfx_flavored_markdown.html?tabs=tabid-1%2Ctabid-a#code-snippet). They are created as real projects, making them runnable, which helps ensure that the code shown in the documentation pages are correct and in working order.
18
18
19
-
## Building and view docs locally
19
+
## Building and Viewing Docs Locally
20
20
21
-
To build and view the documentation locally, a few steps is needed:
21
+
To build and view the documentation locally, following a few steps is required:
22
22
23
23
1. From `docs/site` run `dotnet build`. If you get warnings from running `dotnet build`, try running it again.
24
-
2. From `docs/` run `serve-docs.cmd`, it will start up a local web server, hosting the generated documentation site on http://localhost:8080, using the [`dotnet serve` tool](https://github.com/natemcmaster/dotnet-serve).
25
-
3. After changing samples, from `docs/samples`, run `dotnet test`. This will compile the sample components and run the sample tests.
24
+
2. From `docs/` run `serve-docs.cmd`. This will start up a local web server, hosting the generated documentation site on http://localhost:8080, using the [`dotnet serve` tool](https://github.com/natemcmaster/dotnet-serve).
25
+
3. After changing samples from `docs/samples`, run `dotnet test`. This will compile the sample components and run the sample tests.
26
26
27
-
## Documentation writing rules
27
+
## Documentation Writing Rules
28
28
29
-
- All pages should have a [YAML header](https://dotnet.github.io/docfx/spec/docfx_flavored_markdown.html#yaml-header) with an`UID` to enable easy [cross reference](https://dotnet.github.io/docfx/spec/docfx_flavored_markdown.html#cross-reference) between pages
29
+
- All pages should have a [YAML header](https://dotnet.github.io/docfx/spec/docfx_flavored_markdown.html#yaml-header) with a`UID` to make it easy to[cross reference](https://dotnet.github.io/docfx/spec/docfx_flavored_markdown.html#cross-reference) between pages
30
30
- All page and code references should be created using the [`xref:UID` cross reference syntax](https://dotnet.github.io/docfx/tutorial/links_and_cross_references.html#using-cross-reference).
31
-
-Prefer to include code snippets as sample files in the `samples` projects, using the [code snippet syntax](https://dotnet.github.io/docfx/spec/docfx_flavored_markdown.html#code-snippet).
32
-
- All code snippets should use 2 spaces as an indention unit (1 tab = 2 spaces)
31
+
- By default, you should include code snippets as sample files in the `samples` projects, using the [code snippet syntax](https://dotnet.github.io/docfx/spec/docfx_flavored_markdown.html#code-snippet).
32
+
- All code snippets should use 2 spaces as an indention unit (1 tab = 2 spaces).
0 commit comments