Category Archives: SOLID

Building a Safety Net for Continuous Delivery with Developer Tests

Posted on by

It is impossible to develop a software system with a certain level of complexity unless it is built on top of a smaller working system.

I wanted to credit Bjarne Stroustup for expressing this point of view as early as 1985 in his book The C++ Programming Language, but after re-reading his Notes to the Reader, I see that the quote I remembered was on the importance of well-structured code (in which C++ excels over C), not correctness.

Still, I don’t think I am alone when I claim that we software developers find it natural to develop iteratively, thereby continuously building on top of the last iteration, the last working system.

The question is, how do we know that the system we build on is working?

The truth is that unless we have a very good verification process we don’t know if we build on a working system.

In a good continuous delivery process, we will have waves of verification in the form of continuous integration builds and deployments, automatic and manual testing by testers etc.

Naturally, developers will also develop unit tests as an integrated part of developing code, thereby ensuring that each implemented responsibility behaves as expected in isolation.

But is this good enough? Will it ensure that each iteration builds on a working system?

I think it is not good enough because,

  • Testing is usually decoupled in time and space from the development process.
  • Unit testing only verifies tiny pieces of logic in isolation, but bugs typically show up when these pieces of logic are composed into higher level behaviour.

If you ask me, developers needs to write what I call developer tests.

Developer Tests

A developer test is similar to a unit test, the difference being that we never mock any dependencies unless we absolutely must. For example, we mock external web services that our code calls, but we do not mock database access.

When we run a developer test, we run the exact same code as is run in the production system, which means that the behaviour of the test will closely match the behaviour of the production system. This means that the verification which is done by a developer test is very reliable.

When I develop new code, I always exercise the new behaviour through developer tests. This is typically much easier than setting up the production system with the relevant users with relevant permissions and relevant data to query and alter.

When my new developer tests turn green, I feel confident that my new behaviour works as intended, not only in isolation but also when run in context with huge parts of the existing functionality.

When I have verified that the existing developer tests are green I feel confident that I did not introduce regressions.

Then I check the code changes into the main branch and the new feature will be in the next release a short while after.

What Makes Developer Tests Work

I have developed the concept of developer tests over the last couple of years while working on TradingFloor.com. Since it is now second nature to use developer tests as an integral part of the software development process, it is difficult to remember why this seemed difficult, or impossible, to do just a couple of years ago.

A major part of the reason that developer tests work in TradingFloor.com is that the code is (largely) written with sensible principles in mind, and in this context one of the SOLID principles, the Dependency Inversion Principle (DIP), is essential. And furthermore, using Dependency Injection is practical.

This means that when I exercise my new behaviour through the method Foo on class Bar … 

public class Bar
{
    Bar(IMyDependency1 dep1, IMyDependency2 dep2) { /*…*/}
    void Foo() { /*… use dep1 and dep2 */ }
}

… then I also run the code of the two dependencies (and their dependencies, and their dependencies …), including any kind of logging, interception and whatnot. This is in contrast to a unit test in which I would mock the two dependencies.

In addition to DIP, our experience is that the Command Query Separation (CQS) principle is a great help in general in our code structure, and in particular this principle makes writing developer tests easy. I suppose you can imagine that a code base composed of queries (we call them readers) and command handlers are very handy when building up a test scenario and when asserting the outcome of a test.

Why is the Entire World not Using Developer Tests

Developer tests allow for faster development, they provide fast feedback on correctness during development and they provide a safety net for the future.

Yet, I have not seen a rush for all other developers to get on board and start to use developer tests. Why?

Here are some of the counter arguments I have heard so far,

  • It cannot be done.
    That argument is a couple of years old. Today we are doing it on a daily basis.
  • It is too slow.
    No, our 850+ tests run in one minute on a typical developer PC.
  • Developer tests are very brittle.
    No, it is the other way around. Unit tests are often very brittle because you need to re-do your mocking when refactoring code. Developer tests don’t have this problem and they are surprisingly solid towards refactoring.
  • I cannot do it because my code is much more complex than your code.
    If your code is really complex, working without a safety net is not an option! You can do it.
  • I run a heavy SQL database, tests will be too slow and difficult to set up.
    Right, we run a no-SQL database so building up an entire database per test is fast and easy. Installing the database locally and on any build or test system is also easy and fast. All that will be a hassle with some SQL databases, but not impossible. If you have to, you can isolate SQL access and mock it out but I would prefer not to.

Where Are We Now

I would love to share more details but I feel that I need to introduce developer tests to at least one more project before I can express myself without going into too much detail.

I will come back with more information once I have done that. In the meantime, if you would like me to elaborate on this or that, please ask.

Advertisement

Continuous Delivery – a Safety Net will make you Lazy

Posted on by

I sincerely believe that some kind of safety net is needed when coding.

In fact I believe that having a safety net is especially important when doing continuous delivery.

Before I managed to blog on my opinions regarding this, I read Scott Berkun’s book The Year Without Pants in which Scott makes quite the opposite argument based on his experience from Automattic (and contrary to his experience from Microsoft).

A Safety Net will make you Lazy

Essentially, Scott backs up Automattic’s belief in the philosophy: safeguards don’t make you safe; they make you lazy. This may to a certain extend be true in some cases, as some people drive faster when they get ABS brakes, and football players take more risks because of their padding. And on the same token, if you find yourself in a high tower with no railing, you will be very cautious about every step you take as a fall would kill you. And since you are very cautious, it is unlikely that you will be killed.

Does this philosophy work in software development? Should we skip manual and automatic testing as well as other kinds of verification before we deploy the latest changes to the Live system? Should we essentially skip the entire safety net and rely on developers being very cautious?

No!

Being cautious only takes you part of the way. And if you are too cautious, there will be much needed changes to the code that you will never dare do. Besides, even cautiously made changes could have unexpected effects, regressions, on other parts of the code. If you are too cautious, your code will rot and eventually become unmanageable. (There is a brilliant description of code rot and how to avoid it in Robert C Martin’s book Clean Code)

Still, in a perfect world, coding without a safety net could actually work. In theory it’s simple, and I have already blogged about it. First of all, all changes to code must be small, additive increments – baby steps. Secondly, the code must be crafted by rigorously following the SOLID principles. With a perfect code base with low coupling and high coherence, most baby step changes would consist of adding new code that plug in without changing existing code, or would be a few simple changes to a single existing class, in either case the impact on the system would be restricted and well understood.

Alas, the world is not perfect, neither is the code base that most developers work on.

Besides, sometimes you need to do a refactoring that will impact quite a bit of functionality. Sometimes you change a single or a few lines of code, but there is no simple way to fully understand its impact. In both cases the risk of regressions can be lowered with rigorous verification.

Building a Safety Net

I am quite happy that I read Scott’s book, as it made me think a bit deeper about building up a safety net. (And I can certainly recommend the book to anyone interested in the process of developing software.) Note that what I mention here is regarding the part of the safety net that developers must build and maintain.

Here is my opinion:

  1. Build and maintain automatic tests for non-trivial functionality.
  2. Do not build tests for trivial, unimportant or easily verified functionality.

The second bullet is based on my experience that often huge amounts of tests are made, but the maintenance burden is so high that the tests are not maintained, new tests are not written and (unit) testing in general gets a bad reputation among developers. In such a case, needed refactoring is generally avoided and the code will rot. For these reasons, it is good practice to avoid tests that would only reveal bugs of low severity, of which many would be found anyway, simply with a quick glance at the system.

So the trick is to have exactly the tests that make sense and ensure that they are maintainable.

Even then, a safety net could make a developer lazy. It is never an option to simply throw the code over the fence to the Testing Department, effectively making buggy code somebody else’s problem. Rather, developers must build up a safety net as an integral part of developing code.

Being cautious and having a safety net is the way to go.

Why do some Developers Prefer not to have a Safety Net?

As a final note I have a possible explanation to why Automattic developers prefer working without a safety net.

Scott explains how he once went to India and climbed the stone tower of Jantar Mantar. There was no railing and a fall would kill anyone. But people were cautious because of the lack of safety measures.

I also climbed the stone tower of Jantar Mantar years ago when I was much younger. I clearly remember looking down at our hilarious guide at the ground, but I do not particularly remember the missing railing.

Could it be that focus on safety measures increases with age and experience?

Coding for Continuous Delivery – the SOLID Principles

Posted on by

I never thought that I would find myself blogging on the topic of SOLID Principles. Not that I think it is unimportant, because it certainly is an important topic, it is just that it is so easy to find books, blogs and other written material on the topic already.

On the other hand, people often ask me if it requires a special coding style if you want to implement Continuous Delivery. And I often reply that, no you are not forced to use any specific coding style. But it goes without saying that you need to deliver your code continuously. And in the spirit of Continuous Delivery you need to minimize the risk of each delivery.

Which means that you need to do small (baby-step), additive and non-breaking deliveries.

If you are in the habit of checking in several times a day and you are confident that your code is delivered to the Live environment at the end of each day, or several times a day, then you are good to go and you may not need to read any further.

On the other hand, if you either find it impossible to chop up your implementation into small and additive pieces, you should read on to learn my take on the SOLID principles.

And if you are then still not confident that following the SOLID principles will help you ensure that each of your check-ins can potentially be released any time of day, you will want to read my future blog posts on coding with a safety net and on patterns that fit nicely into all this.

The SOLID Principles

I will not go into details of the SOLID principles but rather sketch how I believe they interrelate in order to make my point. I do not strictly follow Uncle Bob’s original explanation regarding what principle(s) follow by rigorously applying what other principle(s), so you may find my points a bit controversial.

First of all, we need to think about responsibilities in all coding, hence the S – Single Responsibility (SR) – meaning that we want to put code that will change for the same reason together. This means that huge classes or methods are out of the question as these will almost certainly contain multiple responsibilities. One point that many well-meaning developers often overlook is that it is also poor practice to split the code into too small units. Splitting a class with a well-defined and coherent responsibility into several smaller classes will only give you more classes to manage – and the unit tests will be difficult to understand and maintain.

Secondly, we need to think hard about the way we allow our responsibilities to depend on each other. While it might seem obvious that high-level components must depend on lower level components, this kind of code structure tends to create highly coupled systems that are difficult to maintain. The letter D in the SOLID Principles – Dependency Inversion (DI) – states that high level modules must not depend on lover level modules, but rather they should depend on abstractions which do not depend on details.

In day-to-day work I usually state that Dependency Inversion essentially means that a class with a given responsibility must assume that its dependencies are injected into it without the class implementing any of the mechanics needed to get or dispose of the right instances at the right time. These mechanics must be implemented in a single place, the Composition Root, in the program. This day-to-day view is not exactly Uncle Bob’s original thoughts, and also ties into Dependency Injection which is not necessary in order to follow the DI principle. But using Dependency Injection it is, in my opinion, much easier to create a code structure which allows us to do Continuous Delivery.

The impact and importance of Dependency Injection can only be fully understood and appreciated by spending time with it on real-world projects. Personally, I had a hunch before I started to use DI that it could be useful. Today, I find it hard to imagine how to get by without it.

If you can accept that DI is almost a corollary of SR, then you can probably also accept that the way to achieve the O of the Solid Principles – Open/Close (OC) is due to DI and SR. OC means that the code must be open for extension but closed for modification.

When I say that baby steps must be additive, i.e. that new code is added but existing code is left unmodified, then I really refer to OC. When developers respond that OC is hardly ever possible, I acknowledge that it is an ideal that cannot always be achieved but if you pay close attention to the responsibilities of your code and inject all dependencies it is surprisingly often possible to follow OC. I don’t blame developers who get OC explained and then fail to understand how to put it into practice. My advice is to focus on SR and DI for some time, then revisit OC – it will most likely make much more sense then.

The I of the SOLID Principles, Interface Segregation (IS) – means that you should generally depend on client specific interfaces, not concrete implementations. That is almost a no-brainer, as you could not inject dependencies, leaving the IoC container the responsibility to create whatever concrete instance that makes sense, if your code depended on concrete instances. And having bloated, non-client specific interfaces would be a violation of the SR principle.

Depending on interfaces rather than concrete implementations means that you will have classes with interfaces, even though each of those classes only have a single implementation. Some developers dislike that. On the other hand, IS does not demand that all classes have an interface. For example, instances that are essentially values to be passed around can be newed-up independently of the IoC container and do generally not need an interface.

The final letter of the SOLID Principles is L – Liskov Substitution (LS). This principle means that you need to restrict yourself when using inheritance. To some developers, this is highly provocative since inheritance is core to object oriented programming and restricting its use seemingly means crippling the underlying principles of object oriented programming.

Personally, I learned early in my career how easy it is to get into trouble if you happily use inheritance without giving it a second thought. Deep inheritance hierarchies is probably a thing from the past that nobody would create today, but even with a single level of inheritance, even without multiple implementation inheritance, it is so easy to create unmanageable code. I actually abandoned inheritance completely for a few years since I could not see anything but traps and pitfalls. I am happy that Liskov was handling it more intelligently.

LS essentially means that if you inherit a class S from a class T used in your program, then you can use S in your program and it will still work according to requirements. In other words, if your program is working with your composition root set-up with T, it must also work with the composition root set-up with S. Note that the principle goes beyond just plugging-in S to see if it will crash and burn your current system – LS states that you must be cautious whenever you inherit as otherwise you will see problems in the future. It is about maintainability.

Where are we now?

So where does all this leave us? If we follow the SOLID Principles we will automagically have Continuous Delivery?

I am afraid not. Code structure is only one among several cogwheels in the larger machinery of Continuous Delivery.

However, I firmly believe that these principles are essentially common sense and that putting common sense in code will never harm.

In fact, it’s hard for me to imagine how we could have had Continuous Delivery work so well for us in TradingFloor.com if we had not focused on at least Single Responsibility and Dependency Inversion.