.NET Core Integration Testing Basics

hi everyone my name is vasilio linick and today we're gonna take a look at integration testing in the rest API well technically this video is still part of the Habit tracker minimal APAC or Series so if you are interested only in the integration part I will leave a link down below to the GitHub repo so you can get the starting point source code on your machine and follow along for those of you that are following the minimal API Core Series I made a couple of changes to the Habit API however the video got corrupt so I no longer have those recordings but I'll leave a detailed explanation of what's been done in the description below it's just a simple rename of the solution itself so without further Ado let's take a look at integration testing over here we have our habit tracker API with all the endpoint definitions over here if we open this we have a bunch of endpoints today we're gonna take a look at creating integration tasks for the create habit async endpoint to get started you need to create a new project and over here I'm using an unit test project with X unit and we'll need a project name a convention that I picked up some time ago is basically using the name of the Cs project that we are gonna test against so in our case it's habitracker.api then add tests then the type of the test themselves in our case it's integration create this unit project right now and over here we have our first unit test which can be safely removed next what I'll do I'll basically rename this to create a bit endpoint tests because in this class we're gonna test only the create habit endpoint itself to get started with integration testing we will need a couple of nougat packages uh the first one being fluent assertions which is my assertion library of choice next one is Microsoft dot asp.net core dot nvc.testing which is a nougat package that we're gonna use extensively and last but not least I think I need to update the microsoft.net test SDK to a newer version which in our case is 17.60 with that we have all our nuget packages in place okay so to get started with integration testing we will need an instance of our habit tracker API for that we're gonna use the web application Factory class I'm going to show it to you right now real quick so private read only web Factory and as you can see it expects a type argument in here many might use the program.cs but I prefer having a marker interface so in our case it's I API marker so I'm going to add this small interface over here and reuse it in our test so I API marker and I will need to reference The Habit tracker apis so this one web application Factory as an alternative to the I API marker we might use as well the habitant points but right now it's an internal class and we're gonna see how we can test internal classes in another video so for now I'm going to use the IAB marker for the web application Factory in Short what web application Factory does it basically spuns up an instance of our habit tracker API in memory and offers us the possibility to create HTTP clients to connect to the set API next I'll need to generate a Constructor over here and close this one we have our web application Factory and we are injecting it through the DI through the Constructor however we do not want a new instance of the web application Factory for every test that we are going to create so for that I'll need to add an iclass feature with the type of web application API marker so we are using the same web application Factory throughout all our tests and with that said we can start off with writing unit tests so for X unit we are going to use the fact attribute and now public async task now there are a lot of different naming conventions that you might encounter so pick the one that suits you most for habit API tracker we have right here in the context that we have create habit endpoint test I'm going to use a simple one basically given valid habit create habit ah what it does it basically tells us the prerequisite in our case a valid habit and what the API endpoint should do and in our case it should basically create the have if you are familiar with unit testing or with testing in general you might have heard about the AAA approach basically versus a range then we have act and then we have assert in our case in the range side of things we will need an HTTP client to connect to the instance of the API that we are running through web application Factory in our case I'm going to create a new variable client equals web application Factory create client and I'm going to need a new valid Habit in our case habit equals new habit the name of the Habit is going to be integration test so with that we have our arrange part done next we're gonna need to act to do that we're gonna use the HTTP client post async method I'm going to specify the path itself and then The Habit uh now it's not really post is posters Json async and I'm going to assign this to a variable or response equals await versus jsonness and we will need to read the response from our request in our case which will be a created habit those response content read as read from Json async and we're gonna industrialize it to a habit I need to avoid this as well now in the assertion part we're gonna use the fluent assertions Library I'm going to create a separate video where we will go in depth into the assertions library but for now we're gonna use some basic assertions over here so first of all uh response response status should be HTTP status code created should be somewhere here so this is the first assertions that we're gonna make next we're gonna check that the created habit should not be null and that the created habit.name should be the one from habit.net basically that the created habit has the same name that we provided and over here I just need to add an exclamation mark now the last part that we need to check is the location header is the header with the location to where we can check the habits so in our case it's going to be response headers dot location absolute path should be and now um we'll need to specify API V1 habits slash and over here the created habit dot ID now if we put a breakpoint over here and just debug this integration test we can go into the breakpoint into the code so if I go to the next line over here we can see that I have HTTP client that references HTTP localhost next I'm going to go further post to the Json I get a 404 I see my mistake over here it's not habit it's habits now we have a 201 and over here we have a creative habit 3027 and the name is the first integration test next we should go over work so the response is 201 it's not null the name is the one that we are expecting and the absolute path does not match oh yeah I will need a slash up front as well in my test so if I run this unit test again it should pass now an issue over here is basically the fact that if I open my Azure data studio and run a simple select query since we've run the test two times we have this data over here which is not fine since we are not cleaning up the mess after ourselves uh to do that we're gonna imply for now a simple approach namely over here I'm going to create a private list of integer and call it habit IDs and over here just basically habit IDs equals new list of integer and over here add the ID of the Habit that we have created to this set list we're gonna use this list to run some delete requests towards our API after running a specific test for that we're gonna use the I async lifetime interface over here so I'm going to implement methods which is initialize the async and dispose async this one is run before running asset test which basically lets us set up things before we need before a specific test I send people use this instead of the Constructor since the Constructor cannot be async in nature people are using this initialize async in places where they have some setup methods that they need to call in an async fashion in our case it's not really that important so I'm going to just return a task completed for the dispose part though I will need to first get the HTTP client from the same web application Factory create client method and then oh sorry typo here and then for each habit ID inside habits I'm going to call HTTP client delete async and I'm going to specify V1 habits ID and over here as the Habit ID and await this call make this method async yeah and now if I open the data Studio over here delete from Habits sorry for no uppercase SQL but as you can see there are no more habits over here let me just debug this unit test so so we have our habit with the 93 029 run it the Habit is there next go over here so we have the Habit ID itself and we're running and delete async and if I go over here and run it once again I don't have the Habit anymore so right now we are running a test and then cleaning up the data after ourselves in a very simplistic fashion but nonetheless it's a very valid one in part two of the series we're gonna take a look at dusk containers and generating a new database for all our tests and run it there then tear down the whole database itself but for now this is really a valid approach that you can take for disposing of the created data that you have next we're gonna take a look at one last test it's basically the validation part so I'm going to need a new fact public async task given invalid habit returns problem details and I'll need this small part of the range next time only the part for act and one for assert I will need the name for the habit since we want to have it invalid what I need though is this line over here where we send a request to the service and then I'll need a problem await a response content read from Json async and over here validation problem details and for this part we're gonna assert a couple of things so first of all response status code should be unprocessable entity then we'll need to check that the problem should not be null and as well that the problem that errors should not be empty for the areas part we might as well double check that the third that we received is the one that we are expecting in our case it's basically that the name must not be empty so if I run this unit test right now it's okay so that was it for the first video and in the next one we're gonna take a look at the web application Factory and how we can customize it to override some dependencies and in our case we're gonna override the used database and use a test container instead of the database that we have running right now in Docker with that said have a nice day everyone

Channel: Vasilii Oleinic

Views: 3,684

Keywords: Integration Testing, .NET Core, REST API, Minimal API, dotnetcore, dotnet, API, Web Testing, Testing, Docker, TestContainers, Automation Testing, TearDown

Id: 671RRgfXwjA

Length: 14min 41sec (881 seconds)

Published: Sun May 28 2023