There were some gotchas though, so (as always) I made notes:
Whenever you add new code you have to stop running and rebuild before you can send successful requests.
When you do a POST, the port number is 5001 or 5000: It’s whatever you’re using in the browser for GET requests
When you add the Update method, you have to send another POST to create a new Todo item before you can update it. The url is the location field from the response of the POST.
When you add the Delete method, use the GET request in the browser to find the Ids of existing items so you know what you can delete. The url is the same as the Update url, with appropriate Id added on. Use the GET request to check whether deletes have worked. Use the POST to add elements you can then delete.
When you add a new database context you need to update the dependency injection stuff in Startup.cs and you need to make sure your POCO class has an Id property.
If you have a simple .Net console app and you’d like to convert it into a .Net Core app so that you can run it from the command line on any platform (as long as you install .Net Core), here’s what to do:
Remove the following files and folders from your project:
Properties / Assemblyinfo.cs
Create a new temp folder and run this command in that folder: dotnet new console
Take the csproj file created by that command and use it to replace the csproj file in your original project (using the name of the original csproj file).
!! If your original csproj file was in a nested folder, the new csproj file will have to be in the root.
But your program.cs file can stay where it was.
Or you can create a *.sln folder at the root level and add references to any nested csproj files.
To create a sln file: dotnet new sln
To add a csproj file (in a nested tests folder) to your sln file: dotnet sln add .\tests\tests.csproj
Command line: dotnet restore
Now you can build and run the new project from the command line: dotnet run
Check the old project for packages to include:
Look in packages.config
For instance, if you see a line that looks like this:
(I’ve learnt a lot more since I originally wrote this (for instance, how to debug your tests), so this is an updated version).
This weekend I was part of a team that took part in the annual Hack Manchester hackathon (and we won Best in Show! Yay!). We used .Net Core for our back end code, and we got stuck in the middle of the night trying to add tests to our solution. It turned out the solution was pretty simple, so I’m documenting it here.
There are two versions below. The one you choose will probably depend on things like deployment pipelines. If you are doing anything other than a quick hack, Version 1 is probably better.
To be perfectly honest, the only reason I moved from one to another was because I (mistakenly) thought I couldn’t debug the tests or run them in an IDE unless they were in a separate project. It turned out that the only thing preventing me was that I hadn’t installed the relevant extension (see “Debug the tests / run the tests from an IDE” below).
Place tests in a separate project/folder
Keep all the tests in same folder/project as the source. This is quicker / simpler.
Version 1 – keep tests in separate folder/project
This version places tests in a separate project / folder. This is probably better if you want a deployment pipeline.
NB If your source is currently in your root folder, then you’ll need to move it into a separate folder (eg a src folder). This is easy:
Close down any IDEs you have running
Create a new src folder
If you don’t have a *.sln file, create one by opening the project in Visual Studio or running the command: dotnet new sln
Edit your solution file so that your csproj is prefixed by its new folder name
For me that meant changing ” TimeTravelApi.csproj” to “src/TimeTravelApi.csproj”
Move everything except *.sln into your new src folder
Create a separate tests folder in your root folder
Navigate to your new tests folder
Create the nunit project:
There are two ways of doing this.
The first way is to run this command: dotnet new “NUnit 3 Test Project”
The second way is to manually add three new packages: NUnit, Microsoft.NET.Test.Sdk and NUnit3TestAdapter – see below for how to do this manually.
Add a reference to your source project:
Run this command (replace “YourProject” with your project name): dotnet add reference ../src/YourProject.csproj
If you get an error about “incompatible targeted frameworks” then:
Go into your tests.csproj and change the .Net version from 2.0 to 2.1 like this: <TargetFramework>netcoreapp2.1</TargetFramework>
Run this command to upgrade the nunit version: dotnet add package nunit -v 3.11.0
! This works in Oct 2018, but it might be different in the future!
Add your new tests project to the solution:
Navigate back up to your root folder
Command: dotnet sln add ./tests/tests.csproj
Write and run some tests (see “Write and run some tests” below)
Version 2 – keep tests in same folder/project as source
This version keeps all the tests in same folder/project as the source. This is quicker / simpler if you are trying to keep things small and simple.
Add the necessary packages:
You can run the separate package commands on the command line (see below), but you’re probably better off using the dedicated nunit command.
Dedicated nunit command:
Command line: dotnet new “NUnit 3 Test Project”
Separate commands for each package (check versions – this was written Oct 2018):
When trying to verify parameters passed to a method on a mocked object:
• Use Setup (which has taken the place of Expect)
• Use It.Is(x => x == ExpectedParameter)
• The lambda expression can be as complex as you like, as long as it returns a Boolean
• !! Important !! Mark it verifiable!
.Setup(x => x.Method(It.Is(y => y == "expected")))
Use callback: This allows you to store the parameter in your own variable and then make assertions on its contents.
string actual = String.Empty;
mock.Setup(x => x.Method(It.IsAny()))
.Callback((param) => actual = param);