Skip to content

Category: Building future-proof software

Future-proof software. For the longest time, I thought that future-proof software consisted in writing software so good you never need to change it. Over the years, I learned that it is actually software you should be able to change easily. Software that would adapt to future requirements while satisfying the current. Testing is a massive part of that. So is refactoring. Here are some blog posts around these topics.

If you are to embrace new requirements, you must design software so that you can refactor it. If you want to refactor your code, you need to have a way to test its current behaviour no matter how. For a web API, you may even go as far as using Postman to build a test suite.

And remember, whenever you build new production code. Write failing tests. Make the failing tests pass. Push to production. That way you never write unneeded code and if a refactoring is needed you have less to worry about. Yet you have enough to be confident while writing changes.

Continuous delivery for free using Docker, CircleCI and Heroku

Posted in .NET Core, Building future-proof software, and Tutorials

Continuous what?

Continuous delivery. You may recall that in my previous post I announced that today’s entry would be revolving around continuous integration. And technically it can count as such since we will cover continuous integration along the next step. That next step is continuous delivery. If you are not familiar with these terms and the concepts behind them I will sum them up briefly.

Basically, continuous integration allows verifying that your codebase still builds and passes tests passing whenever you push changes. Add a trigger to deploy your code to production upon success and you pretty much have the idea around continuous delivery.

.NET Core CLI Tools: Build a web API in 10 minutes

Posted in .NET Core, Building future-proof software, and Tutorials

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.

HttpResponseSimulator: A simple tool born over an afternoon

Posted in Building future-proof software, and Personal projects

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.

Trying to provide helpful pull request reviews

Posted in Building future-proof software

How I unblocked a frozen pull request

A few weeks ago, I saw a pull request to modify one of our web jobs which codebase is pretty old and had no tests. The pull request had no tests either. The thing is that we decided to make unit testing mandatory for any pull requests a couple of weeks before.

I started reviewing the code when I noticed someone else already posted a review. A pretty laconic “please add tests”. Not a bad nor a mean review but not a really helpful one. Proof of it is that it was posted about an hour before and the pull request was blocked. Indeed we do not untested logic to enter or remain in our software. Yes, it is aligned with our new policy about tests. That being said, the web job code was tightly coupled and pretty impossible to test as it was.

My Musketeers for DotNet Test driven development

Posted in Building future-proof software, and Productivity

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:

D: I don’t have time to write tests.

A: I don’t need to test this.

B: I can’t write a test for this.