RSSAmplifier

Blog

Share the intellectual wealth

principal-it.euRSS feed ↗50 posts

Latest posts

The Saff Squeeze

From time to time, we encounter bugs in the software systems that we work on. That’s part of the life as a software developer. Often, we don’t know the root cause of the defect. So, in order to uncover what is going on we typically start a debugging session. However, when we take a step back and think about defects from a higher level, we can conclude that every bug in the system actually…

Fixing vs Preventing Defects

The way a team handles defects reveals much about how their organisation approaches quality. When every defect must be added to a sprawling backlog with excruciatingly detailed information, it often signals a codebase burdened by technical debt and a product suffering from the consequences of that. Some of these defects may (or may never) be fixed in so-called “stabilisation sprints”. In contrast,…

Tales Of TDD: One Test Double To Rule Them All

So I’ve encountered this specific test case, which is quite elaborate. What do you mean by that? Well, it contains a lot of code, and also looks more difficult to understand compared to the other test cases. Yeah, that’s because of the Fake we’re using in our test code. So, the test code is complex because we’re using a Fake? Yes, I’m afraid so. The test scenario embodies a specific edge case. The…

Perspectives On Software Quality

The quality of software, or any product, can be viewed from different perspectives. This is because there are usually multiple stakeholders, each bringing their own unique views and interests to the table. Some of these perspectives include: The quality of a product as experienced by customers. The quality of a product as perceived by the user, which can be highly subjective and personal. The…

The Five Underplayed Premises Of TDD

Today I got reminded of a great video of GeePaw Hill about the “Five Underplayed Premises Of TDD” . 1. The money premise: When writing tests, we don’t do it for the art of it or other moral reasons. We do TDD because it lets us build more features faster. 2. The judgement premise: There’s no one-size-fits all approach to building quality software. Developers applying TDD use human judgement while…

Contract Tests - Parameterised Test Cases

This is the final installment of a three-part series about contract tests. In the first blog post we’ve discussed the rationale behind contract tests. Next we’ve looked at how to implement contract tests using Abstract Test Cases . In this blog post, we’re going to look into an alternative approach to Abstract Test Cases by using parameterised tests instead. With this alternative approach, we no…

Contract Tests - Abstract Test Cases

In the previous blog post, we’ve discussed the rationale behind contract tests . They are used for exercising those parts of an application that communicate with other parts of the system by crossing the process boundary. In this blog post, we’re going to have a look at how to implement contract tests in practice. The most common approach you’ll likely encounter is Abstract Test Cases . With this…

Contract Tests

One of my favorite awesome talks of all time is Integrated Tests Are a Scam by J.B. Rainsberger. I must admit that the title has a clickbait vibe to it. However, I very much recommend watching the video. So what’s the deal with integrated tests? Why should they be considered as a scam? First of all, let’s clarify what an integrated test actually is. An integrated test is a high-level test that…

The Testing Quadrant

Back in 2003, Brian Marick wrote an excellent article series about agile testing. There he described the concept of the Testing Quadrant. To my recollection this used to be a well-know model that most software developers were familiar with. Although still very much relevant today, I’ve noticed over the years that the knowledge about the different types of testing as described by the Testing…

Tales Of TDD: The Big Refactoring

I’ve heard that you’ve been working on this new feature for the payroll system based on the newly voted government legislation? Yes, I am. How is it going? Seems like a major change. Well, I’m glad you asked. I’ve refactored a large part of the domain based on some new insights I’ve had. This morning I’ve pushed all the code to the git repository. It took me almost two weeks to make the necessary…

Implementing Approval Tests For PDF Document Generation

In the previous blog post, we discussed how to use Approval Tests for verifying generated PDF documents . In this blog post I’m going to show how to extend the Approval Test library for Java in order to support PDF documents. Let’s just dive right into the code. The first thing that needs to happen is making a new implementation of the ApprovalApprover interface, which is provided by the Approval…

Approval Tests For PDF Document Generation

A while back I was confronted with a part of a legacy system that generates PDF documents. This legacy system used a well known library for generating the requested PDF files. The good news was that there were a decent amount of tests available. The not so good news was that these tests made heavy use of test doubles for swapping out most of the types provided by the third-party API. I strongly…

Ignoring Tests

Most test frameworks out there have the capability to disable tests. This is usually done by adding some kind of annotation that instructs the test runner to ignore an individual test method. [TestFixture] public class SomeTests { [Test] public void RegularTest() { ... } [Test] [Ignore] // Ignore a single test public void IgnoredTest() { ... } } It’s also possible to disable all tests of an entire…

Writing Maintainable Unit Tests In Print

I’m very happy to announce that Writing Maintainable Unit Tests is also available as a paper book. Both the ebook and the paper book have been completely self-published. I must say that this whole endeavour was quite an educational experience. The ebook is still available on LeanPub . The paper book can be purchased at most leading book stores: Amazon Barnes & Noble Book Depository IndieBound…

Tales Of TDD: The Case Of Overused Test Doubles

Do you have 15 minutes to spare? Sure, what can I do for you? Well, you know I’ve been working on that new feature we were discussing at the whiteboard last week. I’ve finished the implementation of that user story. All the automated tests are green, the CI build has completed successfully, and I’ve deployed the latest version on the test environment where Luke and I already did some exploratory…

Book Launch: Writing Maintainable Unit Tests

I’m very happy to announce that I’ve finished writing my first book Writing Maintainable Unit Tests . What an amazing journey it has been. I would never have thought that I would be able to write a book. Well now, here we are. The ebook has been published on LeanPub, which is available in PDF, EPUB and MOBI formats. There are six chapters: Chapter 1 provides an overview of the different kinds of…

Avoid Inheritance For Test Classes

Using inheritance for test classes is not a desirable thing as it introduces a number of issues. An abstract base class quite often originates from the desire to share and reuse some code with a number of derived test classes. Maintainable and readable test code should exhibit a nice balance between the DRY principle and the DAMP principle. This balance gets disturbed whenever we introduce a base…

How To Write Unit Tests For Logging

Once in a while I get asked the question whether one should write solitary tests for logging functionality. My answer to this question is the typical consultant answer: “It depends”. In essence, logging is an infrastructure concern. The end result is log data, which is written to a resource that is external to an application. Usually the generated data ends up in a file, a database or it might…

Prevent Domain Knowledge From Sneaking Into Solitary Tests

Previously we discussed why solitary tests should be easy to read . Sometimes, the readability of solitary tests is affected by those developers who overcomplicate or overengineer things. Well intentioned no doubt, but in the end quite harmful nonetheless. Complex solitary tests can cause some serious headaches for other members of the team. One example of this is an issue that I see popping up…

Why Solitary Tests Should Be Easy To Read

Occasionally someone asks me the question whether it’s necessary to test the code of solitary tests ? Usually this question is ushered by folks who are opposed to the idea of automated tests. Somehow they have the notion that one can keep writing tests for tests for tests for tests, etc. Obviously this is a complex and absurd thing to do. This attitude often stems from test code being overly…

Tales Of TDD: Stressed And Always In A Hurry

So I noticed that you completed that feature that we’ve been pair programming yesterday? Yes, I was a little bored yesterday evening. So I decided to continue working on it Great job! Thanks. I’m glad the feature is ready to go. Definitely! I still have one question though. I’ve noticed that you added fifty lines of code to that controller method without adding any tests. What I also noticed is…

Dealing With Date/Time In Solitary Tests

Solitary tests never cross the process boundary in which they are executed. This means that a solitary test never executes code that talks to a database, communicates across the network, touches the file system, etc. This also implies that a solitary test never deals with the system clock either, whether it’s directly or indirectly. Let’s have a look at some example code in order to grasp the…

Announcing Book: Writing Maintainable Unit Tests

I’m very happy to announce that the first draft of my book Writing Maintainable Unit Tests has been published on LeanPub. It’s the written counterpart of my video course , with some significant revisions as well as additional content and examples. The book currently contains the first three chapters. I’m still working on the final two chapters which I expect to be finished somewhere in autumn. The…

Only Test Through Public Interfaces

One of the most commonly asked questions in developer communities regarding Test-Driven Development and unit testing is whether one should write unit tests for private methods, and if so, how to accomplish this. The answer to this question is quite simply: “Of course. As many lines of code as possible should be covered by unit tests”. However, the way we accomplish this is very important. The…

Inside-Out and Outside-In TDD

Test-Driven Development is a discipline that exists for about two decades now. Unfortunately, to this very day, it is still not without controversy. Most professional developers know that writing some form of automated tests can be quite beneficial for any type of codebase. What still seems to be quite controversial is whether to write a test before or after the production code has been laid out.…

Test Double Heuristics

In the previous blog post, we’ve talked about avoiding excessive specification of test doubles . This is just one in a series of “ good practices ” for using test doubles in solitary tests. Let’s have a look at a few more guidelines that increase the maintainability of solitary tests when using test doubles. Avoid using test doubles for types that you don’t own Suppose that we’re using a…

Excessive Specification of Test Doubles

Previously we’ve discussed the different kinds of test doubles . By using test doubles in our solitary tests, we also introduce more coupling between the test code and the implementation. However, the good news is that there are also some things we can do in order to somewhat reduce this coupling. A very important item of caution is to avoid excessive specification of method behaviour. Let’s have…

The Boundaries of Solitary Tests

When stating the definition of a solitary test , we mentioned that they have two constraints: The code being exercised by these tests never cross the process boundary in which they are executed. A single class or module is being tested. The first constraint means that a solitary test never executes code that talks to a database, communicates across the network, touches the file system, etc. … This…

Test Doubles

In the previous blog post, we’ve talked about indirect inputs and outputs when a unit test exercises a Subject Under Test. The examples shown previously demonstrate the use of test doubles. A test double is a type of object that replaces a real instance of a collaborator, for the specific purpose of executing tests. Test doubles make it more easy for us to manipulate indirect inputs and verify…

Indirect Inputs and Outputs

Previously we discussed what state and behaviour verification is about. Depending on the nature of the production code that we’re designing, we might decide to apply one approach over the other. Sometimes this can be quite the dilemma that we face as developers. Which approach should we choose and in which circumstance? Robert C. Martin , also known as Uncle Bob , has named this tension field the…

State versus Behaviour Verification

When reasoning about types of automated tests , I find it quite useful to reason about two different categories, namely solitary and sociable tests. Also see the test pyramid for a more detailed explanation. Focusing on solitary tests, there are generally two different styles that are being used: Solitary tests that perform state verification. Solitary tests that perform behaviour verification.…

Cascading Failures

In a previous blog post, we discussed the test pyramid and why it is a useful model to reason about a healthy mix of solitary and sociable tests. I mentioned that at the bottom of the test pyramid, we have the most isolation. The more we move up the test pyramid, the more integration is employed which results in less design feedback. As soon as we move away from testing a single concrete class or…

The Designing versus Testing Mindset

Previously, we touched on two different categories of automated tests , namely solitary and sociable tests. Also we discussed how and why the test pyramid is a useful model to have a healthy mix of both kinds of tests. The bottom line of the previous blog post is that only having high-level sociable tests without any solitary tests, basically an “ice cream cone” testing strategy, can be quite…

Why Write Maintainable Unit Tests?

Last week I published my very first video course titled Writing Maintainable Unit Tests . It surely has been a very learnful experience. Going through the process of creating the content, recording and editing the videos was definitely quite challenging. But why a video course specifically about writing unit tests? Well, for starters, everything related to Test-Driven Development is something that…

Announcing Video Course: Writing Maintainable Unit Tests

I’m very proud to announce that my first video course has been published on Udemy. This course teaches software developers how to write maintainable and readable unit tests. It’s for people who are serious about investing in their own skills. The launch sale opens today with an additional discount. You can use coupon code TDD-IS-AWESOME to get a huge saving until Monday, March 2, 2020 . Have a…

The Test Pyramid

In the previous blog post , we touched on two different categories of automated tests, namely solitary and sociable tests. We also mentioned that in order to build maintainable and high-quality software systems, we need both solitary as well as sociable tests, but not in an equal amount. Although tests from both of these categories have their strong points and weaknesses, it’s more desirable to…

A Taxonomy Of Tests

It’s more than fair to say that the terminology used in the world of automated tests can be a bit overwhelming. Software people have uncovered all sorts of tests in a wide variety of flavours. For example, there are: Unit tests Integration tests API tests Database tests Acceptance tests UI tests Performance tests Regression tests And much more … You might have heard about some of these kinds of…

Fast Feedback

Test-Driven Development is a discipline that exists for almost two decades now. Unfortunately, to this very day, it is still not without controversy. Most professional developers know that writing some form of automated tests can be quite beneficial for any type of codebase. But what still seems to be somewhat controversial is whether to write a test before or after the production code has been…

Debugability Considered Useful

Developers are lazy. There’s nothing new about that. We even pride ourselves on it. Sometimes being lazy is a good thing, but most of the time it’s not something we should brag too much about. Let’s have a look at a few examples of developer laziness in action. public SomeViewModel Map(Something something) { return new SomeViewModel { Name = something.Name, ListA = something.itemsA.Select(itemA =>…

Blaming Mocks For Bad Design

A while back I stumbled upon this talk titled Built-in Fake Objects . After I’ve watched the first 20 minutes or so, I was so worked up that I almost threw away my iPad just out of complete annoyance. I did eventually came back to watch the rest of the talk. But what bothered me so much? Well, the general theme of this talk is that using mocking frameworks is bad. In itself, there’s really nothing…

Listening to the Vital Signs of TDD

People who know me personally know that I like to go for a long run on a regular basis. I sit and work at a desk all day. So as part of the work I do, labouring the codes, I go for a one or two hour run every other day. I already wrote about this in the past . Besides the obvious benefits one gets from physical exercise, I also learned something quite valuable. I learned how to listen to my body.…

All in the Name of DRY

A while back, I was doing a code review. At some point I encountered some constructs that I see quite often. While I was describing and building my case, I was thinking that I might as well write a blog post about it. The code that I encountered looked similar to the following: public interface IUser { Int32 Id { get; } String FirstName { get; } String LastName { get; } Boolean IsValid { get; } }…

Memo on O-Ring and Software Erosion

One of the most fascinating documents I’ve read to date is the memo from Roger Boisjoly on O-Ring Erosion . The original target audience for this memo he’d written were the management folks of Morton Thiokol back in 1985, about six months before the Challenger disaster. What I find so striking about this whole story is its resemblance to the field of software engineering. We software developers…

Learning F# - The Thunderdome Principle for Functions

Back in 2008, Jeremy Miller introduced the Thunderdome Principle , a technique he used for building maintainable ASP.NET MVC applications which later led to the FubuMVC open-source project . The basic premise of the Thunderdome Principle is to have all controller methods take in one ViewModel object (or none in some cases), and also return a single ViewModel object. One object enters, one object…

Learning F# - Passing Parameters to Functions

One of the first issues I faced when learning F# was finding out how to specify multiple parameters to a function. While this might sound obvious when learning a functional programming language, I had a few confronting moments that forced me to unlearn things before I could make any progress. I wanted to create a function that wrapped the Contains method of the String class. In C#, it would be…

The Burden of Features in Software

I’ve been removing a couple of dead features this week. You know, those features that senior people in organisations like to tell epic war stories about. Those mighty conversations at dinner parties, where a person involved talks about all the pain and sorrow, about how a particular capability ended up in the software, how (crappy) it got implemented, etc … . Everyone at the table is laughing.…

Product or Project Focused

A software development team in an organization should be able to focus on the core domain that reflects the business it’s serving. Developers on the team should be able to iterate and further refine the domain model based on the evolving input and feedback of the domain experts. The business people, domain experts and developers treat the software as a product, further evolving throughout a long…

Premature Abstraction

The first time I read the GoF book , I didn’t understand it. This was because I didn’t had a decent understanding of the principles of object-oriented programming at the time. A while after, I read the book Design Patterns Explained . In this excellent book the author formulated the core thought behind the design patterns in the GoF book. He states that when a particular concept varies, it should…

The Quest for the One True Static Site Generator

When I started blogging back in 2005 I created my personal blog on Blogger . I’ve been using this excellent blogging service over the years, enjoying the luxuries of not having to deal with the intricacies and complexities of hosting providers and blogging engines. Somewhere last year I started to get interested by the rise of static site generators . These days every self-respecting programming…

Using F# in Sublime Text on Linux Mint

I’ve been learning about functional programming for quite some time now, trying to wrap my head around the various concepts that this paradigm has to offer. One of the languages that spiked my interest besides Clojure is F# . The reason for this is quite obvious. As a software developer who uses the .NET framework on a daily basis, I regularly run into the limitations of C#. Embracing a powerful…