This tutorial is an introduction to .NET Core CLI tools. More precisely it is about creating a web API using the CLI tools provided for .NET Core. Whether you are a beginner in development or just new to .NET Core this tutorial is for you. However, you need to be familiar with what an API is and unit tests to fully enjoy this tutorial. Today, we will set up a solution grouping an API project and a test project.
What is the HttpResponseSimulator? Apart from being the least original name. Well, it is a tool that allows simulating the behaviour you want from an endpoint to test an HTTP client and/or wrapper. I built it over an afternoon so that I could write a timeout test for an HTTP client wrapper. I had to get familiar with Node.js and Express again, which I previously used to create HappyPostman. Despite the slow start, it took me about a couple of hours to implement and deploy.
Test, four letters, one meaning and for some people a struggle. Getting people around you to write tests is easy only when everyone already agrees with you. As often, there are instances where some people show resistance to writing tests. Here is the stuff I hear the most from them:
Last month, I posted about Postman enabling you to test your APIs with little effort so that you can build future-proof software. Here we are going to cover setting up continuous integration for a simple project by using Newman to run your Postman collections. You may have heard about continuous integration in the past. Most commonly, continuous integration will build software from one’s changes before or after merging them into the main codebase. Even though there is an infinity of tools that allow implementing continuous integration, I will focus on Appveyor CI. In order to make things simple, I will create a very basic web API project and will host it on GitHub.
Over the past years, we moved more and more towards web-oriented architectures, connecting to services in order to provide information. Along with the evolution of testing tools and development methodologies we can build crazily robust software. However, it happens that sometimes we will not build unit tests because of project constraints. Those reasons often go from time pressure on a project to laziness but I am not here to judge.