This is the first post on automated integration testing in this series but it will not be the last. In this first post we'll look at how to use the Microsoft.AspNetCore.TestHost package to run integration tests of our API. In future posts I want to take a look at SpecFlow (because I love it) and also scripting a short-lived test environment with its own short-lived database which is torn down after the test run.
In the last post we stored the database user password securely as a Docker Secret. In this post we'll look at Docker Configs which uses the same model as the secrets except that files are mounted into the container file system unencrypted.
Why use Docker Configs instead of the other alternatives? Let's quickly compare Docker Configs with other options.
Working with secrets correctly in todays security environment is crucial. Storing database passwords and API keys in plain text files or in the source control system is just plain reckless. There are a few good options out there and today we are going to look at Docker Secrets.
What I really like about Docker Secrets are that it is so simple to use. Complexity is the enemy of security and with Docker Secrets being so simple it is hard to mess it up.
So far we have a relatively simple ASP.NET Core 2.0 Web API that runs directly on the Windows operating system. But the next few posts in the series are going to need Docker. We'll be using Linux containers and looking at configuration, secrets management, and adding a second API. We'll be looking at using Docker Secrets, Docker configuration files, using Hashicorp Vault and creating our first Swarm with two services. So in this post we'll look at the built in Docker support in Visual Studio 2017, look at the various files that get added and what they do.
In the last post we added a short description of the API using markdown. The Description property of the Info class gets rendered at the top of the page above the list of actions.
In this post we are going to take that a bit further. One problem with putting documentation in your Swagger docs is that if you put a lot of detail there then you are forced to scroll down every time you view the Swagger UI of your API. This can get pretty annoying quick. So we'll look at a trick for adding as much detail as you want but avoiding the scrolling issue.
Swagger acts as both machine and human readable documentation for your APIs but also via the Swagger UI offers you a way of interacting with your APIs easily. We are going to embed a Swagger UI in our APIs that will load when you press F5 making it hassle free to test your API during development and testing.
We are going to add Swashbuckle.AspNetCore to our ASP.NET Core 2.0 API to create this embedded Swagger UI.
- API Series Part 1 - Let's Build Something
- API Series Part 2 - Documentation - Swagger
- API Series Part 2b - Add Non-Intrusive Markdown to Swagger UI
- API Series Part 3 - Adding VS2017 Docker Support
- API Series Part 4 - Secrets Management with Docker Secrets
- API Series Part 5 - Configuration with Docker Configs
- API Series Part 6 - ASP.NET Core 2.0 and Integration Testing
In this series we'll build a set of APIs with ASP.NET Core 2.0 in a cloud native, microservices architecture that can satisfy a long list of non-functional requirements.
So what does cloud native actually mean? It means that you don't know where your applications are going to run anymore. Your applications need to be able to work out how they are configured and integrate themselves into the wider system of services and start working. Why is that a desirable thing? Because it means that we can stand them up and down at will, without need for special system configurations. That means we can create copies of them for scaling out and we gain resiliency because when one copy of an application dies we just start up another one.