- .NET Core 3.1
- Visual Studio 2019 with the ASP.NET and Web development.
- Web Compiler (Visual Studio Extension)
To update the generated parts of the documentation set the project MudBlazor.Docs.Compiler as the active project and run it. It generates the following:
- Markup for the documentation examples
- The doc strings for the API pages
- An automatic bUnit test case from every example
We strive for a complete test coverage in order to keep stuff from breaking and delivering a rock solid library. For every component that has C# logic we require a bUnit test that is checking that logic.
When you are making changes to any components and preparing a PR make sure you run the entire test suite to see if anything broke.
When you are writing complex logic, please add a unit test for it. Here are some examples for things that already have unit tests:
- Conversion functions between different data formats (i.e. Date and Time formatsm, etc.)
- Bindable two-way properties of components
- State machines inside of components
Basically everything you fear could break if other developers touch it.
It is actually dead simple. Look at some of the simpler tests like
- StringExtensionTests.cs for normal C# tests
- CheckBoxTests.cs or RadioTests.cs for bUnit tests
Lets say we want to test whether a component's two-way bindable property works
In MudBlazor.UnitTests.Viewer create a razor file that instantiates your component and binds it to a public field.
In MudBlazor.UnitTests create another test (i.e. by copying CheckBoxTests.cs and renaming it) In the Test make sure to instantiate the razor file you just prepared above.
- Assert that the initial state is correct
- Make changes to the public field of the test component and assert that it changes what it should change in the component
- Call Click or other events on the componet and check that the public field was updated properly
You can print the components rendered HTML to the console at different locations of the test to see how state changes affect the HTML or the class attributes. Then write assertions that enforce those changes i.e. by checking that a certain html exists or a certain class is contained or not contained in the class attributes of an element.
We don't need to test the complete rendered HTML of a component, or the appearance of a component. Test the logic, not the HTML. When checking changes in the HTML do simple checks like "does the HTML element exist that depends on a state".
Two things.
- It holds all the test components which are required by the bUnit tests.
- You can run it and try your test components out if you need to debug them.
The documentation has lots of examples for every component. We use those examples as unit tests by instantiating them in a bUnit context and checking whether or not rendering them throws an error or not. While this is not a replacing of a good hand-written unit test we can at least catch very basic breakages which would throw a runtime exception on render. The auto-tests are all generated into the file _AllComponents.cs under MudBlazor.UnitTests.
We have an Azure DevOps pipeline which will automatically execute the entire test suite on all pushes to the master branch.