Software Testing with Fakes instead of Mocks

What are fakes, what are their benefits, and why they are uncontestably preferable over mocks. Also, how to create fakes if needed.

Introduction

50 things expected of developers

Games industry veteran Mike Acton gave talk/rant at GDC (Game Developers' Conference) 2019 where he listed 50 things he expects of developers: https://www.youtube.com/watch?v=cV5HArLYajE  This list was transcribed by Adam Johnson and posted here: https://adamj.eu/tech/2022/06/17/mike-actons-expectations-of-professional-software-engineers/ and I am copying it here for posterity.

I found this list useful as reference material; some of the items on this list do not apply to my job because I rarely do anything especially performance-oriented nowadays, and some of the items on the list are good to always have in mind but subject to the programmer's own judgement, on a case by case basis, whether they should be practiced or not.

Here it is:

The Deployable Design Document

Abstract

A need is identified and a solution is proposed for a novel set of software tools to facilitate the visual composition of technical software design documents as schematic diagrams consisting of predefined software components, and the automatic deployment of runnable software systems from such design documents.

On Microsoft "Visual" products

The logo from Visio version 1.0

This post is intended as support material for another post of mine; see michael.gr - The Deployable Design Document.

One day back in the early nineties, when people were using Windows 3.0 and programming with the Microsoft C/C++ Compiler, a colleague showed me a software design that for the first time he had done not on whiteboard, nor on paper, but on a computer screen, using a new drawing tool called Visio. 

Screenshots of Visio 1.0 running under Windows 3.1. Click to enlarge.

He showed me interconnected components laid out on a canvas, and as he moved one of the components, the drawing tool re-routed the lines to maintain the connections to other components. This meant that Visio was not just a pixel drawing utility like Microsoft Paint; it had some understanding of the structure of the information that was being displayed. 

On Visual Programming Languages

Logos of various visual programming languages

This post is intended as support material for another post of mine; see michael.gr - The Deployable Design Document.

The idea of creating software using visual tools has existed ever since the first aspiring programmer was bitterly disillusioned by discovering that programming almost exclusively entails writing lots of little text files containing nothing but boring and cryptic text.

On UML (oh, do not get me started)

The UML logo, by Object Management Group®, Inc. from uml.org; Public Domain.

This post is intended as support material for another post of mine; see michael.gr - The Deployable Design Document.

The Universal Modeling Language (UML) (Wikipedia) was intended to be a standard notation for expressing software designs, and to replace the multitude of ad-hoc notations that software architects have been using on various mediums such as whiteboard, paper, and general-purpose box-and-arrow diagram-drawing software. The idea was that by following a standard notation which prescribes a specific way of expressing each concept, every diagram would be readily and unambiguously understood by everyone.

It has miserably failed.

A Programming Language

"Coding Software Running On A Computer Monitor" by Scopio from NounProject.com

Abstract

My thoughts and notes on how I would like a new programming language to look like.

The goals of the language are:

• Simple and elegant. (So that it is suitable for the academia.)
• Expressive. (So that it is suitable for experienced programmers.)
• Consistent. (So that it is attractive to developer teams.)
• Guiding. (So that it promotes best practices.) 
• Fast. (So that it is suitable for high performance computing.)
• Lean. (So that it is suitable for resource-constrained computing.)

This is work-in-progress; It is bound to be heavily amended as time passes, especially if I try some new language, like Kotlin or Rust.

Summary of language characteristics

Bathyscaphe

The Bathyscaphe logo, a line drawing of bathyscaphe Trieste

by Mike Nakis, based on art found at bertrandpiccard.com

Abstract

This article introduces Bathyscaphe, an open-source java library that you can use to assert that your objects are immutable and/or thread-safe.

The problem

Programmers all over the world are embracing immutability more and more; however, mutation is still a thing, and in all likelihood will continue being a thing for as long as there will be programmers. In a world where both mutable and immutable objects exist side by side, there is often a need to ascertain that an object is of the immutable variety before proceeding to use it for certain purposes. For example, when an object is used as a key in a hash map, it better be immutable, or else the hash code of the key may change, causing the map to severely malfunction.

Furthermore, when an object is not immutable, there is often the need to ascertain that it is at least thread-safe before sharing it between threads, otherwise there will be race conditions, with catastrophic results.

Note that when any of the above goes wrong, it tends to be a bug which is very difficult to troubleshoot.

White-Box vs. Black-Box Testing

I have something blasphemous to tell you.

Unit Testing is wrong.

There, I said it.

I know I just insulted most people's sacred cow.

Sorry, not sorry.

I will explain, bear with me.

What is wrong with Full Stack Development

Inntel Hotel at Amsterdam, Zaandam

Table of Contents

• What is full-stack development

• Why is full-stack development necessary today

• What is wrong with full-stack development

• Conclusion

What is full-stack development

The predominant web application development model today requires splitting application logic in two parts:

• The front-end, running on the browser.
• The back-end, running on the server.

The front-end is typically written in JavaScript, while the back-end is typically written in Java, Scala, C#, or some other programming language. The two ends invariably communicate with each other via REST. The choice of JavaScript and REST is not due to any technical merit inherent in these technologies, (there is none,) but purely due to historical accident; see michael.gr - The Wild, Wild Web.

A web application developer can either focus on one part of the stack, or work on both parts. Due to reasons that will be explained further down, more often than not, web developers are asked to work on both parts simultaneously. When this happens, it is known as full-stack development.

For the purposes of this paper, we will call full-stack development not just this mode of work, but also this architectural style as a whole: full-stack development is when application logic must be written both on the server and on the client.

Full-Stack Development is a paradox, since it suggests a way of work which is contrary to what common sense dictates. Common sense calls for specialists each working on their own area of specialization, so one would expect to see different developers focusing on different layers of the stack, and nobody ever attempting something as preposterous as working on all layers simultaneously. However, there is a technological hurdle which renders this necessary today.

Why is full-stack development necessary today

The Stateful Microservice

I did a quick search for the term and did not find anything concrete, so I thought I might as well publicly document my thoughts.

Photo of two elephants friendly interacting with each other, from The Scientific American: Fact or Fiction?: Elephants Never Forget

On Stateless Microservices

This post discusses the stateless microservice design pattern; it is meant as support material for other posts of mine that discuss microservices, mainly michael.gr - The Stateful Microservice.

Dory, the yellow-blue fish (a Royal Blue Tang) that suffered from amnesia in the 2003 movie Finding Nemo by Pixar.

Is statelessness a requirement for a microservice?

In another post of mine I discuss what a microservice really is, and I come to the conclusion that despite various attempts out there to define microservices using twenty-item-long lists of characteristics, a good working definition could be as simple as this: 

A microservice is a scalable and resilient module.

(See michael.gr - So, what is a Microservice, anyway?) 

Even if you disagree with the terseness of that definition, and you regard microservices as necessarily more than that, I hope you will at least agree that it is precisely scalability and resilience that the stateless microservice design pattern aims to address, so the definition serves its purpose at least in the context of this series of posts.

There are many who will try to convince you that in order to build a scalable and resilient system, you need statelessness; so much so, that microservices have almost come to be regarded as synonymous with statelessness. This post examines whether this is that in fact so, and what is the cost of doing things this way.

So, what is a Microservice, anyway?

This article attempts to shed some light on what a microservice really is; it is meant as support material for other posts of mine that discuss microservices, mainly michael.gr - The Stateful Microservice.

What is a microservice?

If you go looking for information out there, you will find many different descriptions of what a microservice is; these descriptions exhibit considerable difference of opinion, and to the extent that they agree, it is largely the result of copy-paste. One common theme in these descriptions is that in trying to define this elusive concept, they tend to assign fictitious properties to it. Often, the claims have nothing to do with what a microservice technically is, but rather with impertinent concepts such as the allegedly "independent" software development style around microservices, or some alleged organization of microservices "around business capabilities". Even when the claims do manage to stick within the technical realm, they range from the unwarranted to the preposterous. I have seen statements to the effect that a microservice is supposed to live in its very own source code repository, that a microservice must be independently deployable, that microservices must communicate with each other via REST, etc. (My favorite one is that they must necessarily be stateless; more on that in another post of mine; see  michael.gr - On Stateless Microservices.)

What is wrong with Scala

This is part of a series of posts in which I am documenting what is wrong with certain popular programming languages that I am (more or less) familiar with.  The aim of these posts is to support a future post in which I will be describing what the ideal programming language would look like for me.  

I will be amending and revising these texts over time.

What is wrong with C#

This is part of a series of posts in which I am documenting what is wrong with certain popular programming languages that I am (more or less) familiar with.  The aim of these posts is to support a future post in which I will be describing what the ideal programming language would look like for me.  

I will be amending and revising these texts over time.

What is wrong with Java

This is part of a series of posts in which I am documenting what is wrong with certain popular programming languages that I am (more or less) familiar with.  The aim of these posts is to support a future post in which I will be describing what the ideal programming language would look like for me.  

I will be amending and revising these texts over time.

What is wrong with C++

This is part of a series of posts in which I am documenting what is wrong with certain popular programming languages that I am (more or less) familiar with.  The aim of these posts is to support a future post in which I will be describing what the ideal programming language would look like for me.  

I will be amending and revising these texts over time.

Malicious Inaction

Actor Wayne Knight in the original Jurassic Park movie
playing the role of the unscrupulous programmer Dennis Nedry,
(anagram of "Nerdy",) the main villain.

Malicious Inaction (noun) any situation where a piece of software encounters an unexpected condition and responds by deliberately doing nothing, including not throwing an exception.  Synonyms: Silent Failure; Deliberate Malfunction; Unscrupulous Programming; Undermining; Sabotage; Treachery; Subversion; Vandalism.

I think that the term "Silent Failure" fails to express the amount of harm done.  Sure, the word "failure" indicates that something went wrong, but the word "silent" somewhat lessens the severity of the term, and it makes sound as if no feathers were ruffled, so it may have been alright.

Well, no. It was not alright. It never is. We need a stronger term to better capture the harm caused by the sinister practice of hiding error. We need a term that clearly conveys wrongdoing, a term that assigns blame and shame.

Hence, I present to the world my new and improved term: Malicious Inaction.

SVG in WPF

My notes on how to use SVG graphics in a WPF application

The Goal

The goal is to be able do do things like this:

    <Button Content="{StaticResource mySvgImage}">

... where mySvgImage somehow stands for a vector image that has somehow been obtained from an SVG file.  

The solution must not involve any proprietary, closed-source libraries.

Naturally, we want one of the following:

• either directly include SVG files into our application as resources, or, if that is not possible, then 
• have an "asset pipeline" approach where our SVG files are automatically converted during build into some format which is suitable for inclusion as a resource.

Java with Maven: Giving CI/CD a try

Please note that this is work in progress.  I am still working on it and refining it, as my understanding of it improves.

I have a set of public repositories on GitHub showcasing my work, (⬀) which is in java with maven. These projects are interdependent, so when you check out one of them, in order to compile and run it you need the binaries of some of the others. You could manually check out all of them and put them in an IDE project, but that's too much work. Solving this problem requires having Continuous Integration & Continuous Deployment (CI/CD) in place, so I decided to try my luck in setting one up using free services only.

The process involves three entities:

• A Source Repository.  (Where our source code is hosted.)
• I use GitHub for this.
• Possible alternatives:
• GitLab
• BitBucket
• A CI/CD provider. (Where the actual CI/CD takes place.)
• I decided to use CircleCI for this, but in retrospect it was a bad idea, because it does not support GitLab.
• Possible alternatives:
• GitLab - I want to use it as a source code repository, and I don't want to put all my eggs in one basket, so I don't want to use it for anything else.
• GitHub - I want to use it as a source code repository, and I don't want to put all my eggs in one basket, so I don't want to use it for anything else.
• BitBucket - it is by Atlassian. Need I say more.
• Appveyor - gives various errors like "There was an error while trying to complete the current operation. Please contact AppVeyor support." -- Lots of open source projects are using it though, so it might be worth a second try.
• Travis CI - only works with github.
• JFrog - overwhelmingly fancy front page followed by a not particularly fancy user experience once you get past the front page. Once I have registered, there is no way for me to log back in. 
• semaphoreci.com - only works with github.
• buddy.works - after you have given them your e-mail address, they tell you that it is free but they require a valid payment method.
• atlassian.com/software/bamboo - it is by Atlassian, need I say more.
• drone.io - not only it works with nothing other than github, they assume that I am using github, which is very annoying.
• octopus.com - registration fails with "Please use your work email address."
• buildkite.com - might work; not particularly user friendly.
• codefresh.io - might work; they unnecessarily complicate things with mandatory docker images.
• An Artifact Repository. (Where the binaries are stored.)
• I found a place called Repsy for this; Repsy is minimalistic, unrefined, and they even have bad English on their web site, but it will do for now.
• Possible alternatives:
• GitHub Packages
• GitLab Package Registry
• JFrog Artifactory

We begin with a situation where we already have the Source Repository (GitHub) and we want to set-up the CI/CD Provider (CircleCI) and the Artifact Repository (Repsy).