How to Unit Test an Existing C# App? Easy—With a Mocking Tool

This content originally appeared on Telerik Blogs and was authored by Viktoria Grozdancheva

I suggest we take a look at the ERP app for starters: 

The times I have seen or interacted with it can be counted on the fingers of a hand. But that should not bother me, or you (well, at least not a lot). 

Forgot to mention something about JustMock – it follows the Arrange-Act-Assert Pattern. The AAA Pattern makes a test look simpler and more structured by dividing it in three subsections, as explained below: 

Having the JustMock extension installed, you are guaranteed a flying start. The project templates that come with it helped me create a test project in seconds. 

Now, I'm ready for unit testing! 

Edit / Remove Orders 

See the edit and delete buttons at the left below the Breadcrumb bar? I bet there is a Command related to both.

Noticed that the Orders item is initially selected? Surprisingly (or not) its DataContext is the OrdersViewModel. Back to the commands—yup, there they are: 

this.EditRecordCommand = new DelegateCommand(
    (o) =>
    {
        dialogFactory.TargetItemName = this.ItemName;
        dialogFactory.ShowEditDialog(this.ItemToEdit);
        this.Refresh();
    },
    (o) => this.ItemToEdit != null);
 
this.DeleteRecordCommand = new DelegateCommand(
    (o) =>
    {
        dialogFactory.TargetItemName = this.ItemName;
        if (dialogFactory.ShowDeleteDialog())
        {
            (this.ItemToEdit as ISavableObject).Delete();
            this.Refresh();
        }
    },
    (o) => this.ItemToEdit != null);

Let us see how the above can be covered with unit tests and write our first ones with Just Mock! The purpose of both tests—suppose there is a direct binding between the buttons and the commands. This way, we will be able to test the commands themselves. All dependencies (e.g., the ERPDialogFactory, the SalesOrderHeader, the CollectionView) will be mocked and the successful execution of the respective methods (e.g., the ShowEditDialog, ShowDeleteDialog, Refresh)—verified. Starting with the EditRecordCommand. 

[TestMethod]
public void OrdersViewModel_EditRecordCommandExecutedSuccessfully()
{
    //Arrange
    var dialogFactory = Mock.Create<ERPDialogFactory>();
    var salesOrderItem = Mock.Create<SalesOrderHeader>();
    var collectionView = Mock.Create<QueryableDataServiceCollectionView<SalesOrderHeader>>();
    Mock.Arrange(() => new ERPDialogFactory()).Returns(dialogFactory);
    Mock.ArrangeSet(() => dialogFactory.TargetItemName = "myItemName");
    Mock.Arrange(() => dialogFactory.ShowEditDialog(salesOrderItem)).DoNothing();
    Mock.Arrange(() => collectionView.HasChanges).Returns(true);
    Mock.Arrange(() => collectionView.RejectChanges()).InOrder();
    Mock.Arrange(() => collectionView.Refresh()).InOrder();
 
    //Act
    var viewModel = new OrdersViewModel();
    viewModel.SelectedItem = salesOrderItem;
    Mock.Arrange(() => viewModel.ItemName).Returns("myItemName");
    Mock.Arrange(() => viewModel.Items).Returns(collectionView);
    viewModel.EditRecordCommand.Execute(null);
 
    //Assert
    Mock.Assert(dialogFactory);
    Mock.AssertSet(() => dialogFactory.TargetItemName = "myItemName", Occurs.Once());
    Mock.Assert(salesOrderItem);
    Mock.Assert(collectionView);
}

Covering the DeleteRecordCommand with a unit test looks a lot like the EditRecordCommand's: 

[TestMethod]
public void OrdersViewModel_DeleteRecordCommandExecutedSuccessfully()
{
    //Arrange
    var dialogFactory = Mock.Create<ERPDialogFactory>();
    var salesOrderItem = Mock.Create<SalesOrderHeader>();
    var collectionView = Mock.Create<QueryableDataServiceCollectionView<SalesOrderHeader>>();
    Mock.Arrange(() => new ERPDialogFactory()).Returns(dialogFactory);
    Mock.ArrangeSet(() => dialogFactory.TargetItemName = "myItemName");
    Mock.Arrange(() => dialogFactory.ShowDeleteDialog()).Returns(true);
    Mock.Arrange(() => salesOrderItem.Delete()).DoNothing();
    Mock.Arrange(() => collectionView.HasChanges).Returns(true);
    Mock.Arrange(() => collectionView.RejectChanges()).InOrder();
    Mock.Arrange(() => collectionView.Refresh()).InOrder();
 
    //Act
    var viewModel = new OrdersViewModel();
    viewModel.SelectedItem = salesOrderItem;
    Mock.Arrange(() => viewModel.ItemName).Returns("myItemName");
    Mock.Arrange(() => viewModel.Items).Returns(collectionView);
    viewModel.DeleteRecordCommand.Execute(null);
 
    //Assert
    Mock.Assert(dialogFactory);
    Mock.AssertSet(() => dialogFactory.TargetItemName = "myItemName", Occurs.Once());
    Mock.Assert(salesOrderItem);
    Mock.Assert(collectionView);
}

Print These Orders 

What about the print button at the right below the Breadcrumb bar? That button:

<telerik:RadButton
    x:Name="Print"
    local:PrintExportHelper.PrintTarget="{Binding ElementName=gridView}"
    Style="{StaticResource GridNavigationButtonStyle}"
    Width="63">
    <!--
        Button content and tooltip here
    -->
</telerik:RadButton>

It has a PrintTarget set and I am guessing this is what I'm looking for. Let's peek at where this PrintTarget comes from and what it is supposed to do. This appears to be a dependency property, the setter of which will be called, and respectively—the PropertyChanged, when the above Binding is executed. This leads us to: 

private static void OnPrintTargetChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
    var button = d as RadButton;
    var gridView = e.NewValue as RadGridView;
    if (button != null && gridView != null)
    {
        button.Command = new DelegateCommand(OnPrintCommandExecuted);
        button.CommandParameter = gridView;
    }
}
 
private static void OnPrintCommandExecuted(object obj)
{
    var gridView = obj as RadGridView;
    if (gridView != null)
    {
        var spreadsheet = new RadSpreadsheet();
        var window = new RadWindow() { Width = 0, Height = 0, Opacity = 0, Content = spreadsheet };
        window.Show();
        spreadsheet.Workbook = gridView.ExportToWorkbook();
        spreadsheet.Print(new PrintWhatSettings(ExportWhat.ActiveSheet, false));
        window.Close();
    }
}

Let's start from the button's XAML definition this time and test whether the binding is correctly resolved and respectively—clicking this button does its magic. 

[TestMethod]
public void PrintExportHelper_PrintButtonClickExecutesPrintCommand()
{
    //Arrange
    Mock.NonPublic.Arrange(typeof(PrintExportHelper), "OnPrintCommandExecuted", Arg.Expr.AnyObject);
 
    //Act
    var printButton = Mock.Create<RadButton>();
    var args = Mock.Create<DependencyPropertyChangedEventArgs>();
    var gridView = Mock.Create<RadGridView>();
    Mock.Arrange(() => args.NewValue).Returns(gridView);
    PrivateAccessor.ForType(typeof(PrintExportHelper)).CallMethod("OnPrintTargetChanged", printButton, args);
    printButton.Command.Execute(gridView);
 
    //Assert
    Mock.Assert(typeof(PrintExportHelper));
}

This unit test does not seem sufficiently stable enough. It only ensures that there is a print button and when it is clicked, the static method of the above helper class is called. But does it function properly, i.e., what exactly happens when the button's command is executed? Let us test: 

[TestMethod]
public void PrintExportHelper_PrintCommandExecutionSucceeded()
{
    //Arrange
    var gridView = Mock.Create<RadGridView>();
    Mock.NonPublic.Arrange(typeof(PrintExportHelper), "OnPrintCommandExecuted", gridView);
    var spreadsheet = Mock.Create<RadSpreadsheet>();
    var workbook = Mock.Create<Workbook>();
    var window = Mock.Create<RadWindow>();
    Mock.Arrange(() => window.Show()).IgnoreInstance().InOrder();
    Mock.Arrange(() => window.Close()).IgnoreInstance().InOrder();
    Mock.Arrange(() => gridView.ExportToWorkbook());
    Mock.Arrange(() => spreadsheet.Print(Arg.IsAny<PrintWhatSettings>(), null)).IgnoreInstance();
 
    //Act
    PrivateAccessor.ForType(typeof(PrintExportHelper)).CallMethod("OnPrintCommandExecuted", gridView);
 
    //Assert
    Mock.Assert(typeof(PrintExportHelper));
    Mock.Assert(gridView);
    Mock.Assert(window);
    Mock.Assert(spreadsheet);
    Mock.Assert(workbook);
}

Here, we need to arrange three more things (apart from those in the previous test)—the window, the spreadsheet and its workbook (these will do the magic of exporting the grid data into a spreadsheet's workbook). 

The act we are performing is calling the OnPrintCommandExecuted method with the mocked grid view. 

The assert phase ensures that all the above arrangements were made, this time including the ones regarding the grid, the spreadsheet and its workbook apart from the PrintExportHelper. 

This is the happy path of the print functionality. What about passing an item, different than the expected grid view—e.g., an empty string, to the print command? Let us cover that with a test—assuming we passed a fake argument, the print command execution is expected to fail, right? 

[TestMethod]
public void PrintExportHelper_PrintCommandExecutionFailed()
{
    //Arrange
    var gridView = Mock.Create<RadGridView>();
    Mock.NonPublic.Arrange(typeof(PrintExportHelper), "OnPrintCommandExecuted", gridView).OccursNever();
    var spreadsheet = Mock.Create<RadSpreadsheet>();
    var workbook = Mock.Create<Workbook>();
    var window = Mock.Create<RadWindow>(Constructor.NotMocked);
    Mock.Arrange(() => window.Show()).IgnoreInstance().InOrder().OccursNever();
    Mock.Arrange(() => window.Close()).IgnoreInstance().InOrder().OccursNever();
    Mock.Arrange(() => gridView.ExportToWorkbook()).OccursNever();
    Mock.Arrange(() => spreadsheet.Print(Arg.IsAny<PrintWhatSettings>(), null)).IgnoreInstance().OccursNever();
 
    //Act
    PrivateAccessor.ForType(typeof(PrintExportHelper)).CallMethod("OnPrintCommandExecuted", String.Empty);
 
    //Assert
    Mock.Assert(typeof(PrintExportHelper));
    Mock.Assert(gridView);
    Mock.Assert(window);
    Mock.Assert(spreadsheet);
    Mock.Assert(workbook);
}

Guess what, it did. Not the test. The command execution—we arranged that no invocations of the above methods have ever occurred when acting with an empty string instead of the expected grid view. 

Well, seems like the export, delete and print functionalities work as expected. Good job! 

What about the last button of this button bar—the export? Well, I'm leaving this as your JustMock homework.  

Try It Out 

If you are intrigued (hopefully you are ), I'll be more than happy to hear your honest feedback in the comments. 

Whether you: 

Regardless of the above ‘cases,’ don't be shy to:

 Try The Latest JustMock Now

You won't regret it.

This content originally appeared on Telerik Blogs and was authored by Viktoria Grozdancheva

Print Share Comment Cite Upload Translate Updates

APA

Viktoria Grozdancheva | Sciencx (2021-02-11T02:57:05+00:00) How to Unit Test an Existing C# App? Easy—With a Mocking Tool. Retrieved from https://www.scien.cx/2021/02/11/how-to-unit-test-an-existing-c-app-easy-with-a-mocking-tool/

MLA

" » How to Unit Test an Existing C# App? Easy—With a Mocking Tool." Viktoria Grozdancheva | Sciencx - Thursday February 11, 2021, https://www.scien.cx/2021/02/11/how-to-unit-test-an-existing-c-app-easy-with-a-mocking-tool/

HARVARD

Viktoria Grozdancheva | Sciencx Thursday February 11, 2021 » How to Unit Test an Existing C# App? Easy—With a Mocking Tool., viewed ,<https://www.scien.cx/2021/02/11/how-to-unit-test-an-existing-c-app-easy-with-a-mocking-tool/>

VANCOUVER

Viktoria Grozdancheva | Sciencx - » How to Unit Test an Existing C# App? Easy—With a Mocking Tool. [Internet]. [Accessed ]. Available from: https://www.scien.cx/2021/02/11/how-to-unit-test-an-existing-c-app-easy-with-a-mocking-tool/

CHICAGO

" » How to Unit Test an Existing C# App? Easy—With a Mocking Tool." Viktoria Grozdancheva | Sciencx - Accessed . https://www.scien.cx/2021/02/11/how-to-unit-test-an-existing-c-app-easy-with-a-mocking-tool/

IEEE

" » How to Unit Test an Existing C# App? Easy—With a Mocking Tool." Viktoria Grozdancheva | Sciencx [Online]. Available: https://www.scien.cx/2021/02/11/how-to-unit-test-an-existing-c-app-easy-with-a-mocking-tool/. [Accessed: ]

rf:citation

» How to Unit Test an Existing C# App? Easy—With a Mocking Tool | Viktoria Grozdancheva | Sciencx | https://www.scien.cx/2021/02/11/how-to-unit-test-an-existing-c-app-easy-with-a-mocking-tool/ |

Please log in to upload a file.

There are no updates yet.
Click the Upload button above to add an update.

You must be logged in to translate posts. Please log in or register.