Davide Guida | my personal thoughts about life, coding, the universe and everything.

my personal thoughts about life, coding, the universe and everything.

Show menu Hide menu

Page 2 of 23

Unit, integration, end-to-end tests: do I need all of them?

9 May 2018 / / 0 Comments

Yes. I mean, don’t even think about it. You’ll need all of them, probably in different measures, but there is no “we shipped to production without tests”.

Tests are the first rampart separating you from madness and failure.
Why madness? Try to do even a small refactoring after you’ve deployed your app. Without automatic tests you’ll have to manually probe the entire system (or systems if you’re on microservices).

Why failure ? Simple, just think on the long run. Maintenance will quickly become a hell and adding new features will soon bring you to the infamous “it’s better if we re-build this from scratch”.

So! Where should we start? From the pyramid!

the test pyramid

The test pyramid. Image taken directly from Martin Fowler’s article. Thanks, Martin.

Starting from the bottom, you’ll begin with writing the unit tests. “Unit” here means that you’re testing a single small atomic piece of your system, a class, a function, whatever. You won’t connect to any external resource (eg. database, remote services) and you’ll be mocking all the dependencies. 
So, ideally you’ll be checking that under specific circumstances a method is throwing an exception or the cTor is populating the class properties or the result of a computation is a specific value giving a controlled input.
Also, unit tests have to be extremely fast, in the order of milliseconds, giving you a very quick and generic feedback of your system.

Next is the “Service” layer or, more commonly, “Integration”. This is where things start to get interesting. Integration tests check that two or more pieces fit correctly and the cogs are oiled and greased.  So stuff like your Persistence layer, access to the database, ability to create or update data and so on. They might take more time than  unit tests and probably will be in a lesser number, but their value is extremely high.

Then we have the “UI” or “end-to-end” tests. Here we’re making sure that the whole system is working, inspecting from the outside, with little to none knowledge of the inner mechanism. You’ll be checking that your API routes are returning the right HTTP statuses, setting the proper headers and eating the right content types.

In the end it’s all a matter of perception. The point of view is moving from the inside of the system, the developer perspective, to the outside: the consumer perspective.

There are of course other typologies of tests, acceptance, smoke, functional and so on. But if you begin adding the coverage using this pyramid you’ll save an awful lot of headaches and keep your system maintainable and expandable.

Feature Gating

Feature Gating part 3 : how can we check the gates?

7 March 2018 / / 0 Comments

In this article we’ll explore few ways to check if the feature gates are opened or not. This is the third episode of our series about Feature Gating, last time we discussed about the optimal persistence method for the flags.

The first approach is a static config object injected as dependency in the class cTor:

It’s simple, easy to implement and does the job. The configuration object can be instantiated in the composition root reading data from whatever is your persistence layer  and you’re done.

Drawbacks? It’ static. That means you cannot vary your flags based on custom conditions (eg. logged user, time, geolocation).

So what can we do? Something like this:

Replacing the configuration object with a specific service will do the job. This is probably the most common situation and personally I’m quite a fan. The only drawback is the infamous tech debt: very soon the code will be filled with if/else statements. Should we leave them? Remove them? If yes, when? We will discuss in another article a simple strategy for that.

Speaking about strategy, it’s a very interesting pattern that we can exploit:

The idea is to encapsulate the new and the old logic in two classes (lines 10 and 11) and generate a third one which will use the previous featureService to pick the right instance. Finally all you have to do is to inject that class in the consumer and you’re done.  

Next time: this is nice, but is really useful? What do we really get using Feature Gating?

Feature Gating

Feature Gating part 2 : how can we store the flags?

28 February 2018 / / 0 Comments

In the first article of this series we discussed the general concept behind Feature Gating, now we will talk a little about how we can store the flags.

A very naive approach is using a simple file per environment. You can serialize your flags in any way you want, json, xml, ini… then all you have to do is reading this configuration during the application startup and you’re done. 
It’s a very simple method and works very well for small applications and prototypes. Of course you have to remember to deploy the configuration every time something changes. Also you’ll have to implement some sort of flags hot-reloading in the application, otherwise the only option is restarting it (or if you’re under IIS, waiting for app pool recycling).
I said “one file per environment” because I’m pretty sure you have different configurations on DEV, UAT and production. Maybe you want all your flags to be on on DEV and only a small subset on production. Whatever suits your needs.

The next obvious step is persisting the flags in the application database. You can start with a simple table with the flag name and the boolean value.
Later on it will be possible to extend the system by creating relationships to the other tables according to your specific business logic. For example you might want to link flags to user profiles/permissions to allow only subsets of user accessing the features. 
This approach gives more flexibility during deployment, although you still need the hot-reloading. Also, linking the flags table to others might create unnecessary clutter and prevent splitting the monolith.

Let’s move forward to another approach: a key/value storage. Redis can be a very good candidate but here’s a list, just in case. 
Using this kind of databases you have few nice advantages: first of all you can decouple the feature gating from your application using a microservice.
Also, it would be possible to easily store different types of data not just boolean flags. Suppose for example that you want a feature to be enabled only for users in Canada and Japan. A solution could be storing the country codes in the flag value instead of true/false.

The last step is using a third party service. That means you’ll have to write the integration but most of the times there will be libraries already. Just make sure to pick a product with good documentation and decent user base.
Of course you won’t have anymore control over your data and in the worst case you might have to “bend” a little the system to accommodate your application needs. It’s something that happens every time an external solution is used: might cover 90% of the functionalities you need…but that 10% could require a lot of refactoring on your side.

In the next article I’ll show some design patterns you can use in your code to check the feature gates. Stay tuned!

Feature Gating

Feature Gating part 1 : what is it?

26 February 2018 / / 0 Comments

Last week I was invited as speaker at the monthly DevDay Salerno to talk about Feature Gating. The recording will be soon available on YouTube (even though it will be in italian, sorry).

Seems that the topic captured some interest so I thought it was a good idea to write a little about it here. 

In this series of articles we will

  • discover what Feature Gating is
  • what strategy can we use to persist our data
  • some design patterns
  • how Feature Gating can help us and why should we be using it
  • how to fight the infamous tech debt

So let’s start!

As I wrote already in my last post, Feature Gating is an interesting and easy tool to leverage when you want more flexibility during production deployment. It helps controlling and shipping new features faster allowing practices like canary releases and A/B testing.

But what’s the heart of it? An IF block. Nothing else. 

Suppose you’re asked to rewrite a functionality, the first thing you would probably do is commenting the old code and replace it with a new function. Something like this:

Then (probably, hopefully) you update your tests and deploy to production. And right after you discover that maybe

  • the code is not exactly doing what it’s supposed to do
  • performances are lower than expected
  • a bug slipped through
  • whatever

So how can you control this without updating the code and deploying again? Let’s see a very simple solution:

We introduced another actor, this “checkFeatureIsOn” function. It will take the name of the feature and return a boolean flag indicating whether or not use the new codepath.

In the next article we will explore how would you store all the flags. Stay tuned!

« Older posts Newer posts »

© 2018 Davide Guida

Theme by Anders Noren — Up ↑