Artificial Code Coverage

Abstract:

In this paper I put forth the proposition that contrary to popular belief, 100% code coverage can be a very advantageous thing to have, and I discuss a technique for achieving it without excessive effort.

Types of dependencies

The term "dependency" is used very often in software engineering, but depending on context, it may mean slightly different things. To avoid confusion, here are the different meanings of the term, and their explanations.

Call Graph Acyclicity

Abstract

In technical design of software systems as conventionally practiced, call graphs often contain cycles. We show that cyclic call graphs are highly problematic for a number of reasons, the most important being that they require careful handling on a case-by-case basis by custom-written code, thus preventing the standardization, and therefore the automation, of system assembly. We discuss refactoring strategies for systematically eliminating call cycles, including a universally applicable technique for trivially eliminating a certain common type of call cycle. We conclude that since call cycles can be avoided or eliminated, they can be comprehensively disallowed, thus paving the way for the standardization and automation of system assembly.

Towards Authoritative Technical Software Design

Abstract

In this paper we examine the long-standing need within the Software Engineering Discipline for technical design documents that are authoritative. A design document is authoritative if there exist technical means of materializing it as a running software system, thus guaranteeing that the end result is indeed precisely as described by the design. We notice the scarcity and inadequacy of existing solutions, we look into the difficulties involved in the creation of such documents, and we conclude with some realizations on what it would take to come up with a solution that works.

Definition: Collaborator

I have been coming across the term collaborator in software literature, and I have been using it too in my own writings, but without having seen it defined. I tried searching for its definition, but could not find any. In UML the term collaboration is vaguely described, but not the term collaborator. After asking on Software Engineering Stack Exchange I was pointed to what is in almost all certainty the original definition, but it turns out that it is very old, and slightly problematic, so I thought I should provide a modern definition here, at the very least for use in my own writings.

Here it goes:

A collaborator is a component invoked by another component to do a job.

(And since the context is software, these are, of course, software components.)

Origin of the term

If you are using mock objects you are doing it wrong.

Abstract:

The practice of using Mock Objects in automated software testing is examined from a critical point of view and found to be highly problematic. Opinions of some well known industry speakers are cited. The supposed benefits of Mock Objects are shown to be either no real benefits, or achievable via alternative means.

Collaboration Monitoring

Abstract:

An automated software testing technique is presented which solves the fragile test problem of white-box testing by allowing us to ensure that the component-under-test interacts with its collaborators according to our expectations without having to stipulate our expectations as test code, without having the tests fail each time our expectations change, and without having to go fixing test code each time this happens.

On messages and message-passing

Over the decades, numerous software system architectures have emerged which require invocations across subsystems to be done via message-passing instead of programmatic interface method calls. Such architectures are so common that many programmers have come to regard message-passing as an end in and of itself, oblivious of the fact that it is nothing but a (poor) technical mechanism for accomplishing a certain architectural goal.

Intertwine

Abstract

A mechanism is described for automatically converting method invocations of any programmatic interface into a single-method normal form and converting back to invocations of the original interface, so that general-purpose operations can be performed on the normal form without explicit knowledge of the interface being invoked. Implementations are provided for C# and for Java.

Incremental Integration Testing

Abstract:

A new method for Automated Software Testing is presented as an alternative to Unit Testing. The new method retains the benefit of Unit Testing, which is Defect Localization, but eliminates the need for mocking, thus greatly lessening the effort of writing and maintaining tests.

Software Testing with Fakes instead of Mocks

Abstract:

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

Introduction

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 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.

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

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.

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.

Is statelessness a requirement for a microservice?

In another post (see michael.gr - So, what is a Microservice, anyway?) 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.

Even if you disagree with the terseness of this 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 statelessness in microservices aims to address, so my 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.)

The MVVM architectural design pattern

Here is a brief technical explanation of MVVM, which contains enough detail (borrowed from its WPF implementation) and examples to allow the reader to grasp how it actually works.