tests Archives - CodeJourney.net

Write Test Progress To The Console With NUnit

Dawid Sibiński — Sun, 19 Jun 2022 13:07:28 +0000

I recently needed to write test progress to the console with NUnit. The task we want to solve here is basically the TODO part of this snippet:

	[TestFixture]
	public class MyTests
	{
	[Test]
	public void SampleTest()
	{
	// some operations here, like starting a server for tests in-memory…

	// TODO: inform the 'user' (the one who runs the test) that the server is already running
	while (true)
	{
	// keep it running on purpose (e.g. for E2E tests)
	}

	}
	}

view raw NUnit_test_progress_todo.cs hosted with ❤ by GitHub

The title picture of this article shows the end result. If you want to know the solution, keep reading

Context

The context of this need is very simple. I have a unit test in which I want to perform some operations and keep the test running indefinitely afterwards. The use case might be instantiation of an in-memory test server. After that, I want to inform the user (programmer or the one running the test) that the server is up and running. I want to do that before the test finishes. In other words: I want to write the test’s output while it’s still running.

In my case, I was running two .NET Core apps in-memory. The backend server app and the ASP.NET Core web application. In the process, the web app got its IP address assigned dynamically. Meaning that the IP was different with each test run. This particular test was used to run the app in-memory and let the user manually use the application. It means the user must know the IP/URL of the in-memory web app. That’s why I needed to output the dynamic IP address into the NUnit test output

Solution

The solution to write test progress to the console with NUnit is very simple. To do that, use TestContext.Progress.WriteLine(string) method from NUnit.Framework namespace:

	[TestFixture]
	public class MyTests
	{
	[Test]
	public void SampleTest()
	{
	// some operations here, like starting a server for tests in-memory…

	TestContext.Progress.WriteLine("The server is running now! You can reach it on https://localhost:8067/");
	while (true)
	{
	// keep it running on purpose (e.g. for E2E tests)
	}

	}
	}

view raw NUnit_test_progress.cs hosted with ❤ by GitHub

And that’s it! I’m publishing this simple solution, because it took me some time to find

I previously tried with TestContext.Out.WriteLine, System.Diagnostics.Trace.WriteLine and System.Console.WriteLine, but all of them output the text after the test finishes.

Finally, you can also run the test from cmd using dotnet test:

Hope it’s useful!

The post Write Test Progress To The Console With NUnit appeared first on CodeJourney.net.

Improve your tests with Assert Object Pattern

Dawid Sibiński — Mon, 09 Nov 2020 20:42:34 +0000

Today I’d like to share with you a very interesting concept in software testing – Assert Object pattern. It makes the Assert part of a test much simpler and more readable. Let’s dive right into it

The Asserts Hell

Let’s consider the following unit test:

What’s wrong here? Given and When sections are great single-liners. We know straightaway what’s the input and the action executed. However, Then block is too complex. It’s hard to figure out, just passing quickly through this test, what is expected. This case is even not that bad thanks to the usage of FluentAssertions.

I spend a lot of time writing tests (unit or integration), but I spend even more time reading them. I always hope that I will find these idyllic tests that act as code documentation…

However, let’s go step by step. I recently took place in a software testing course. That’s where I discovered the solution to The Asserts Hell.

Assert Object for Better Asserts

Assert Object pattern is what solves our problem. The idea is to create an Assert class which wraps the original object being tested. In our case the tested object is of Product class, so our assert class will be called ProductAssert.

Let’s see the implementation:

As you can see, we simply moved the asserts from our test’s Then section into ProductAssert class’s methods. Additionally, we always return this from each asserting method, which allows chaining functions calls.

We can now use such assert object in our unit test:

You must agree it’s much more readable now

We can of course improve it even more, for example by wrapping these 3 assertion methods (BeAvailable(), HaveDiscount() and Cost()) into a single one. We can also easily create an extension method for the Product class itself, so the assert object doesn’t have to be instantiated in our unit test. I could even add an extension to FluentAssertions library.

You can find complete source code used as examples in this article here.

Assert Object – summary

I personally find Assert Object a very useful tests code refactoring method. As a programmer, you spend most of your time not on writing, but on reading the source code. Clear and simple tests can make your (and your colleagues’) life much better

Of course, the Assert Object pattern should not be your default way of asserting. If you can complete your test with one or two assertions, then it’s probably better to keep it without wrapping into any additional objects. Having too many assert statements might also mean that the objects being tested are poorly designed. However, as we often work with legacy code which we can’t easily change or refactor, it might be a good solution.

What patterns for writing better tests do you use? Share your tips in the comments!

The post Improve your tests with Assert Object Pattern appeared first on CodeJourney.net.

Unit Testing Xamarin application

Dawid Sibiński — Sat, 25 Mar 2017 23:07:19 +0000

Today we’ll see how to add unit tests to Xamarin Android application, testing both platform-independent logic and Android-specific features.

Issue with unit tests in Visual Studio 2017

When I started to create my data access methods in MoneyBack, I really wanted to start writing even some basic unit tests of that logic.

My first trial was to add a new project to my solution which contains unit tests. So I checked what kind of projects templates I have available and I I found Unit Test App (Android) project template and added it to my solution. Generated project contained TestsSample class with some unit-looking tests methods, but I had no idea how to execute them. With ReSharper installed, I didn’t have any “Run Tests” option on this project. I read somewhere on the web that this project type is used to execute tests on the device, but I couldn’t figure out how to do it. I gave up.

Then I found another project template – Class Library (Android) with nUnit. Sounds better, nUnit in the name suggests unit tests, so I added this project to my solution. This time when right-clicking the project I had “Run Tests” option, but when clicking on it I got the following exception coming from ReSharper:

ReSharper error when executing unit tests

“Hmm… Visual Studio 2017”, I thought. “Some bugs for sure”. And I…

… didn’t give up this time and with some help of folks from StackOverflow I figured out how unit tests should be done in Xamarin app. Let’s see that in the next chapters.

Levels of testing Xamarin application

There are basically three “levels” of testing Xamarin apps:

Classic unit tests of pure .NET/Mono
- standard, good old unit tests of logic independent from targeting platform (Xamarin.Android/iOS/Windows Phone)
- unit-testing frameworks can be used (nUnit / xUnit)
Platform-specific tests
- unit tests of functionalities specific to targeting platform (e.g. Bluetooth, Location, GPS, SMS etc.)
- specific for each platform
- don’t contain GUI tests
- executed on the emulator/device
UI tests
- tests of UI elements of the app and how those react for input (touch) events
- executed by cloud/testing lab services (local or remote)

We’ll dive into the first two, UI tests is more complex topic, which requires setting up tests lab or using cloud testing services. For small projects, in the beginning it’s not necessary.

Classic platform-independent unit tests

In order to simply use ReSharper for executing unit tests of logic, which is independent from Android/iOS/Windows Phone, there is a need to add a new project using template Unit Test Project (.NET Framework) to our Xamarin solution.

To such project, you can add your favourite unit-testing framework (such as nUnit or xUnit) by simply installing it from Nuget. After, ReSharper allows to run your unit tests as in old good times:

nUnit tests executed by ReSharper

The exception I was getting with ReSharper previously was because I added the project using template Class Library (Android) which has its target set to Android device/emulator. ReSharper doesn’t know about any Android-specific (or Xamarin-specific) testing, so it was displaying unhandled error.

Platform-specific unit tests

In order to test platform-specific (in out case Android-specific) functionalities of your application, the tests need targeting runtime environment to run. It means they need to be executed on the physical device or emulator. Providers of the most popular unit-testing frameworks created wrappers for on-device testing. I’m using NUnit Xamarin Runners.

First of all, a new project should be added to our solution. To make things easier, download NUnit Templates for Visual Studio (although it officially supports VS up to 2015, it also works in VS 2017) and install it. After, add new project using appropriate template – I chose NUnit 3 Test Project (Android). What’s interesting, the newly created project contains MainActivity class with the following content:

	public class MainActivity : global::Xamarin.Forms.Platform.Android.FormsApplicationActivity
	{
	protected override void OnCreate(Bundle savedInstanceState)
	{
	base.OnCreate(savedInstanceState);

	global::Xamarin.Forms.Forms.Init(this, savedInstanceState);

	// This will load all tests within the current project
	var nunit = new NUnit.Runner.App();

	// If you want to add tests in another assembly
	//nunit.AddTestAssembly(typeof(MyTests).Assembly);

	// Do you want to automatically run tests when the app starts?
	nunit.AutoRun = true;

	LoadApplication(nunit);
	}
	}

view raw

MainActivity_Tests.cs

hosted with ❤ by GitHub

As you can see, this is an Activity, so it will be launched as a separate app with its own GUI. It’s built using Xamarin.Forms. The comments in auto-generated class are obvious, so I won’t explain the details here. That’s just what nUnit wrapper for Android on-device tests does – it allows to be run as a separate, small application with a GUI allowing to run unit tests directly on the device (similarly to ReSharper tests runner we use directly in Visual Studio).

One testable piece of MoneyBack application is the Repository used for database operations (by the way I refactored and made it generic, you can see how it looks currently on GitHub), so I added RepositoryTests class to MoneyBack.Android.Tests project with two test methods:

	[Test]
	public void one_new_person_inserted_adds_one_new_row()
	{
	// given
	var person = new Person()
	{
	Name = "A",
	LastName = "B"
	};

	var repo = new Repository(InMemorySqliteConnection);

	// when
	var numRows = repo.Insert(person).Result;

	// then
	Assert.AreEqual(1, numRows);
	}

	[Test]
	public void new_person_added_has_id_primarykey_generated()
	{
	// given
	var person1 = new Person
	{
	Name = "A",
	LastName = "B"
	};

	var person2 = new Person
	{
	Name = "A",
	LastName = "B"
	};

	var repo = new Repository(InMemorySqliteConnection);

	// when
	var n1 = repo.Insert(person1).Result; // getting Result in order to force Task's completion before continuing
	var n2 = repo.Insert(person2).Result;

	// then
	Assert.Greater(person1.Id, 0);
	Assert.AreEqual(person2.Id, person1.Id + 1);
	}

view raw

RepositoryTests_methods.cs

hosted with ❤ by GitHub

The interesting part is that as I’m using SQLite database in my app, I wanted to test it without creating database file on the device. For that purpose, when creating SQLiteAsyncConnection in order to initialize my Repository, I passed to its constructor a “:memory:” string, which makes SQLite database created in-memory (there is no physical file created):

	public SQLiteAsyncConnection InMemorySqliteConnection;

	[OneTimeSetUp]
	public void Init()
	{
	InMemorySqliteConnection = new SQLiteAsyncConnection(":memory:");
	}

view raw

RepositoryTests_sqlite.cs

hosted with ❤ by GitHub

Such database lives in device’s memory only for the time of our unit tests.

After having tests written, there’s a time to execute them. As the project contains MainActivity class, we simply deploy and run it on a device/emulator, which presents the following view:

Device – tests results

If any of our tests is not passed, we can see the failure’s details:

Device – test failed

We can of course debug our units tests in Visual Studio. The GUI on the device also allows to re-run the tests and see results of all of them.

Summary

We’ve seen how to add two new projects to Xamarin solution: one containing platform-independent unit tests (old good ones), the other one testing Android-specific stuff which is run directly on the device or emulator.

For bigger and more “real” apps, UI testing would also be necessary. This however requires using some cloud testing lab or setting up your own testing environment. More details can be found here.

If you have any experience in testing Xamarin applications, share your insights/advices

The post Unit Testing Xamarin application appeared first on CodeJourney.net.