Testing components that uses DevExpress components

[egil]

Testing components that uses DevExpress components seems to work quite well. Be aware that, when you write these tests, don't waste time writing tests that tests DevExpress' components. Write your tests such that you primarily target your own code, and don't waste assertions on DevExpress' output, unless you need to.

The recording of how this came to be will be available on YouTube at https://youtu.be/dh_eCrHxnvs from 2021/04/13. Until then, you can watch the recording on twitch.tv/egilhansen, as long as it is archived there

Here is an example that tests the following DataGrid.razor component:

@page "/datagrid"
@using BlazorApplication1.Data

<h2>DevExpress Data Grid</h2>

<p class="pb-2 pt-2">
    The DevExpress Data Grid for Blazor allows you to display and manage data via a tabular (rows/columns) UI metaphor.
    This page uses our Blazor Data Grid component to display weather forecast values.
</p>

<DxDataGrid Data="@Forecasts"
            RowRemoving="@OnRowRemoving"
            RowUpdating="@OnRowUpdating"
            RowInserting="@OnRowInserting"
            InitNewRow="@OnInitNewRow">
    <Columns>
        <DxDataGridCommandColumn Width="100px" />
        <DxDataGridDateEditColumn Caption="Date" Field="Date" />
        <DxDataGridColumn Caption="Temperature" Field="TemperatureC" />
    </Columns>
</DxDataGrid>

@code {
    [Parameter]
    public List<WeatherForecast> Forecasts { get; set; } = new List<WeatherForecast>();

    DataGridEditMode CurrentEditMode { get; set; } = DataGridEditMode.EditForm;

    internal void OnRowRemoving(WeatherForecast dataItem)
    {
        Forecasts.Remove(dataItem);
    }

    internal void OnRowUpdating(WeatherForecast forecast, IDictionary<string, object> newValue)
    {
        MapForecastToData(forecast, newValue);
    }

    internal void OnRowInserting(IDictionary<string, object> newValue)
    {
        var forecast = new WeatherForecast();
        MapForecastToData(forecast, newValue);
        Forecasts.Add(forecast);
    }

    internal Task OnInitNewRow(Dictionary<string, object> values)
    {
        values.Add(nameof(WeatherForecast.Date), DateTime.Now);
        values.Add(nameof(WeatherForecast.TemperatureC), 0);
        return Task.CompletedTask;
    }

    void MapForecastToData(WeatherForecast forecast, IDictionary<string, object> newValue)
    {
        foreach (var (field, value) in newValue)
        {
            switch (field)
            {
                case nameof(WeatherForecast.Date):
                    forecast.Date = (DateTime)value;
                    break;
                case nameof(WeatherForecast.TemperatureC):
                    forecast.TemperatureC = int.Parse(value.ToString());
                    break;
            }
        }
    }
}

And here is the necessary code to test it:

using System.Collections.Generic;
using System.Threading.Tasks;
using BlazorApplication1.Data;
using BlazorApplication1.Pages;
using Bunit;
using DevExpress.Blazor;
using FluentAssertions;
using Microsoft.Extensions.DependencyInjection;
using Xunit;

namespace Project.Tests.Pages
{
    public class DataGridTest : TestContext
    {
        public DataGridTest()
        {
            Services.AddDevExpressBlazor(o => o.SizeMode = DevExpress.Blazor.SizeMode.Small);
            JSInterop.Setup<string>(invocation => invocation.Identifier == "DxBlazor.Grid.dispose").SetResult(string.Empty);
        }

        [Fact]
        public async Task Works_With_Add_New_Feature_Through_Markup()
        {
            var forecasts = new List<WeatherForecast>();
            var cut = RenderComponent<DataGrid>(ps => ps.Add(p => p.Forecasts, forecasts));

            // Adding new item
            cut.FindButtonWithText("New").Click();
            cut.FindButtonWithText("Update").Click();

            forecasts.Should().HaveCount(1);

            // Editing existing item
            cut.FindButtonWithText("Edit").Click();
            cut.FindInputForField("Temperature").Change("42");
            cut.FindButtonWithText("Update").Click();

            forecasts.Should().ContainSingle()
                .Subject
                .TemperatureC
                .Should()
                .Be(42);

            var dxGrid = cut.FindComponent<DxDataGrid<WeatherForecast>>();
        }

        [Fact]
        public async Task Works_With_Add_New_Feature_Through_Component()
        {
            var forecasts = new List<WeatherForecast>();
            var cut = RenderComponent<DataGrid>(ps => ps.Add(p => p.Forecasts, forecasts));

            var newRow = new Dictionary<string, object>();
            // Verify correct working InitNewRow method attached
            await cut.Instance.OnInitNewRow(newRow);
            newRow.Should().ContainKey("Date");

            // Verify correctly working RowInserting method
            cut.Instance.OnRowInserting(newRow);
            forecasts.Should().HaveCount(1);

            // Editing existing item
            newRow["TemperatureC"] = 42;
            cut.Instance.OnRowUpdating(forecasts[0], newRow);

            forecasts.Should().ContainSingle()
                .Subject
                .TemperatureC
                .Should()
                .Be(42);
        }
    }
}

The code above shows two different tests that verifies the same thing. The difference between the two is that the first triggers the various events through the event handlers in the DevExpress component which then calls DataGrid components event handlers, the ones we/you write.

The second, on the other hand, with the help of the InternaVisibleToAttribute added to the production code project, just invokes the event handler methods directly, completely taking the DevExpress component out of the test. This does have the advantage of being less dependent on how the DevExpress component works, but it skips on testing that the right properties/parameters has been set on the DevExpress component.

Note the common set up logic in the tests constructor. With the component under test in this example, that was the only thing we needed to do, to make the test run without a problem.

The following helper extensions makes it easier to get at the right bits of markup rendered by DevExpress:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using AngleSharp.Dom;
using Bunit;

namespace Project.Tests
{
    public static class DevExpressDOMSelectorExtensions
    {
        public static IElement FindButtonWithText(this IRenderedFragment cut, string text)
        {
            cut.WaitForAssertion(() => FindElementWithText(cut, "button", text));
            return FindElementWithText(cut, "button", text);
        }

        public static IElement FindInputForField(this IRenderedFragment cut, string fieldName)
        {
            cut.WaitForAssertion(() => FindElementWithText(cut, "label", fieldName));
            var label = FindElementWithText(cut, "label", fieldName);
            var inputId = label.GetAttribute("for");
            return cut.Find($"#{inputId}");
        }

        public static IElement FindElementWithText(this IRenderedFragment cut, string elementSelector, string text) 
            => cut.FindAll(elementSelector).Single(x => x.TextContent.Trim() == text);
    }
}

When testing any component library, your own or others, it is a really good idea to wrap common tasks such as "find a button the text" in extension methods that you can reuse across your tests. Its especially important when your tests are relying on a 3rd party library that might change the markup they produce, which could cause all your tests that rely in it to fail. If you have a set of common methods that handles the markup, then you just need to update one thing and all your tests goes green again.

[mycarrysun]

@egil this is a great set of helpers - I was wondering if you knew of a way to just find all elements (not giving a css selector) with a certain text content? Something similar to this:

cut.FindAll().Where(el => el.TextContent.Trim() == text);

[egil]

cut.Nodes has the "root level" nodes/elements for the rendered fragment/component represented by cut. From there it's just a matter of traversing the AngleSharp DOM like normal.

[mycarrysun]

Ok - I had started down that path but didn't know if there was a built in method. Thanks!

[mycarrysun]

Is there a way to convert from INode to IElement?

[egil]

An IElement is a INode. So if you have an actual element at hand, then a simple cast should do it.