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
Copy file name to clipboardExpand all lines: CHANGELOG.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -373,10 +373,10 @@ The latest version of the library is availble on NuGet:
373
373
374
374
-**Added logging to TestRenderer.** To make it easier to understand the rendering life-cycle during a test, the `TestRenderer` will now log when ever it dispatches an event or renders a component (the log statements can be access by capturing debug logs in the test results, as mentioned above).
375
375
376
-
-**Added some of the Blazor frameworks end-2-end tests.** To get better test coverage of the many rendering scenarios supported by Blazor, the [ComponentRenderingTest.cs](https://github.com/dotnet/aspnetcore/blob/master/src/Components/test/E2ETest/Tests/ComponentRenderingTest.cs) tests from the Blazor frameworks test suite has been converted from a Selenium to a bUnit. The testing style is very similar, so few changes was necessary to port the tests. The two test classes are here, if you want to compare:
376
+
-**Added some of the Blazor frameworks end-2-end tests.** To get better test coverage of the many rendering scenarios supported by Blazor, the [ComponentRenderingTest.cs](https://github.com/dotnet/aspnetcore/blob/main/src/Components/test/E2ETest/Tests/ComponentRenderingTest.cs) tests from the Blazor frameworks test suite has been converted from a Selenium to a bUnit. The testing style is very similar, so few changes was necessary to port the tests. The two test classes are here, if you want to compare:
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
+
## 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.
7
+
8
+
## Bugs and feature requests?
9
+
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
+
## Contributing code and content
12
+
13
+
bUnit accept fixes and features! Here is what you should do when writing code for bUnit:
14
+
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
+
- 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
+
- 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
+
- Any code or documentation you share with the bUnit projects should fall under the projects license agreement.
20
+
21
+
Here are some resources to help you get started on how to contribute code or new content.
22
+
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.
25
+
26
+
### Identifying the scale
27
+
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
+
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
+
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
+
34
+
### Submitting a pull request
35
+
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.
0 commit comments