testing

Recently I was working on some Cypress tests, the first time I used them if I had to be honest, and I came across an issue. I wanted to run the test files individually but when I tried the solutions I found on the internet (StackOverflow and so on), no one of them worked for me. My setup was very bare, I didn’t even have a front end project as my tests involved sending requests to an API and asserting the HTTP responses, and the JSON values in the body. Being very new to Cypress I’m not sure if the following is the right way to go but I was executing the tests using command prompt and then reading the results using MochAwesome and an HTML file it produced. When researching online I read that there’s a some sort of a UI for running tests and reading results, but that was not my approach.

Instead I went for this approach. Inside the integration folder I created subfolders for each environment I wanted test. That is the reason why I had separate, individual files. Different environments have different credentials and environment variables. In the individual subfolders I had my JS test file. So roughly, my directory was like this

->root
  ->cypress
    ->integration
      ->development
        ->testfile.js
      ->staging
        ->testfile.js
      ->production
        ->testfile.js
  ->node_modules
  ->cypress.json
  ->package.json
  ->package-lock.json

Once I had that setup all I had to do was execute the following command on cmd.

npx cypress run --spec "cypress/integration/development/**"

Worth noting that if there had to be more than one JS test file inside a particular subfolder, say development, in that case all of the JS test files will be executed so yes I admit, technically speaking the title of this blog post isn’t accurate because this solution works for just one JS test file per subfolder, but hey who’s not guilty of implementing a not so clean solution?

Anyway, thanks for reading and I hope this is useful to some frustrated developer who can’t find a way to run cypress tests the way he/she wishes.

See you next post,
Bjorn

Hello again, and welcome to yet another blog post. In today’s post I shall be discussing how does one go about with integration testing a cosole application. As opposed to unit testing, integration testing (as the name implies) tests different units or components together as a group. The idea is to test how they will interact together and make sure that all the modules, as a whole, pass the functional requirements.

From my previous experience I was familiar with integration testing a standard .NET Core API. For that we would normally use a WebApplicationFactory and create an instance of the API based on its configuration. In the case of a console application I adopted a slightly different technical approach, the idea is still the same; create an instance of the application. Also, the console application that I was testing was the one I built in my previous post here and here.

As usual I created a new testing project and a new class, called it ApplicationTests. In here I added a new function that will create an instance of ProcessStartInfo object. This class can be used to start processes and in my case I used it to start the console application executable file found inside the bin folder of my solution. This function will be called at the beginning of each integration test. If you remember correctly the console application relied on an appsettings.json file for it’s configuration, and one of the values inside that configuration was the directory of the setup file.

For my integration tests I will have different setup files, with different moves for the turtle to execute, to see what outcome the application will return. Therefore for each setup file I had to create a new appsettings.json file and in each I had to make a reference to the different setup files. Once I had my setup files and different appsettings.json files ready, I had to copy the test appsettings.json file to the bin folder of my solution, the same directory where the executable file lies.

	public class ApplicationTests
	{
	private const string testAppSettingsFileDirectory = @"C:\<path>\<SolutionName>\<IntegrationTestsProject>\TestAppSettings";
	private const string binAppSettingsFileDirectoryAndName = @"C:\<path>\<SolutionName>\<ConsoleAppProject>\bin\Debug\netcoreapp3.1\appsettings.json";

	protected Process StartApplication(string testAppSettingsFileName)
	{
	File.Copy($"{testAppSettingsFileDirectory}\\{testAppSettingsFileName}", binAppSettingsFileDirectoryAndName, true);
	ProcessStartInfo processStartInfo = new ProcessStartInfo();
	processStartInfo.FileName = @"C:\<path>\<SolutionName>\<ConsoleAppProject>\bin\Debug\netcoreapp3.1\EscapeMines.exe";
	processStartInfo.WindowStyle = ProcessWindowStyle.Hidden;
	processStartInfo.CreateNoWindow = true;
	processStartInfo.UseShellExecute = false;
	processStartInfo.RedirectStandardInput = true;
	processStartInfo.RedirectStandardOutput = true;

	return Process.Start(processStartInfo);
	}
	}

view raw integrationtestingconsoleone.cs hosted with ❤ by GitHub

I added a few properties to the process that I start in my tests so that for instance no console application window would show during execution, or input and output aren’t read or written from a file. Now I just needed to write my tests. For these tests I followed the same AAA (Arrange, Act, Assert) pattern. Arranged each test to load a particular setup file, acted by running the application and asserted by reading the output of the application and compared it with the expected outcome.

	public class ApplicationTests
	{
	private const string testAppSettingsFileDirectory = @"C:\test\EscapeMines\EscapeMines.IntegrationTests\TestAppSettings";
	private const string binAppSettingsFileDirectoryAndName = @"C:\test\EscapeMines\EscapeMines\bin\Debug\netcoreapp3.1\appsettings.json";

	protected Process StartApplication(string testAppSettingsFileName)
	{
	// implementation
	}

	protected Task<string> WaitForResponse(Process process)
	{
	return Task.Run(() =>
	{
	var output = process.StandardOutput.ReadLine();

	return output;
	});
	}

	[Fact]
	public void RunApplication_TurtleIsLost_ReturnStillInDanger()
	{
	// Arrange
	var process = StartApplication("appsettingsLost.json");

	// Act
	var outputTask = WaitForResponse(process);
	outputTask.Wait();
	var output = outputTask.Result;

	// Assert
	Assert.Equal("Still in Danger – The turtle did not hit a mine but didn't find the exit either.", output);
	}

	[Fact]
	public void RunApplication_TurtleFindsExit_ReturnsSuccess()
	{
	// Arrange
	var process = StartApplication("appsettingsExit.json");

	// Act
	var outputTask = WaitForResponse(process);
	outputTask.Wait();
	var output = outputTask.Result;

	// Assert
	Assert.Equal("Success – The turtle has found the exit.", output);
	}
	}

view raw integrationtestingconsoletwo.cs hosted with ❤ by GitHub

I used xUnit testing framework but just like unit tests, this would also work just fine with other testing frameworks such as NUnit. I also added the full solution to GitHub in case anyone would want to have a better look at it, and have a working version too.

This concludes our blog post for today. Hope this was insightful to you and if you normally implement this differently then feel free to leave your thoughts in the comment section below.

Until next blog post,
Bjorn ✌️

It's not a bug, it's a feature

from the average coder to the average coder

executing specific test files on cypress

integration testing a .net core console application