Audit Testing

Abstract

An automated software testing technique is presented which spares us from having to stipulate our expectations in test code, and from having to go fixing test code each time our expectations change.

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.

The most important quality of software

What is the most important quality of software?

Correctness, they say.

And what is the second most important quality of software?

Readability, they say.

That is right, but only in theory.

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.

On the "Dotfuscator" tool by PreEmptive Solutions

I am giving this tool a try at work, and I am encountering a great many problems with it. I decided to publicly document my findings.

[SOLVED] Maven deploy fails with status 422 unprocessable entity

It has been more than a year since I created this question on GitHub Community; a couple of days after that I found the solution by myself, so I answered my own question, and to this date comments keep being added by people who were helped by my post.  

When I look at it today, I notice that my answer has this particular style, this grumpy indignation which has become so characteristic of me, after a lifetime of battling with lame software, and even worse, with lame error messages. 

I thought I should share this on my blog for posterity.

Here is the link:

Program Code is Uncountable

There are some words in English that are uncountable. For example: "fish", "sheep", "bread", etc. When we want to speak of many of those things, we do not say "fishes", "sheeps", or "breads"; we still use the singular form: "I caught lots of fish", "Please count the sheep", "Do not eat too much bread", etc.

Hyrum's Law

With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.

Hyrum's Law

(From https://www.hyrumslaw.com/)

A few good reads from Simplethread

I found them at a place called Simplethread while randomly browsing. 

I thought I'd post links here for posterity.

Taming Names in Software Development by Joseph Glass (2022)
https://www.simplethread.com/taming-names-in-software-development

Agile at 20: The Failed Rebellion by Al Tenhundfeld (2021)
https://www.simplethread.com/agile-at-20-the-failed-rebellion

20 Things I’ve Learned in my 20 Years as a Software Engineer by Justin Etheredge (2021)
https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer

Debating with other Software Engineers

Stackoverflow and the whole Stackexchange network is good for asking very narrowly-scoped questions that can receive objective and preferably authoritative answers that cite documentation or definitions. Any kind of question which is subject of opinion, or liable to elicit debate, is off-topic there. This means that stackoverflow is only good for asking strictly technical questions, and there is an upper limit on how valuable this can be. Sure it can be very helpful when you are trying to solve a specific technical problem, but in the grand scheme of things, it is irrelevant; from a philosophical point of view, it is trivial.

I have been looking for ways to discuss with other software engineers (preferably experts) issues that are related to software engineering but are in fact very much subject of opinion. These are the interesting questions. I do of course already have my own opinions, which tend to either deviate or be diametrically opposite from the prevailing industry trends, so it would be very useful to me to debate these issues with others to see what they have to say. Clearly, either I am wrong, or the entire industry is wrong; wouldn't it be nice if we could debate this and have it settled?

To this effect, I decided to give a few forums a try, to see if it is possible to have debates in any of them. As it turns out, there seem to be very few options available, and things are rather quiet in each one of them; most people seem to be doing nothing but consuming content generated by influencers instead of participating in discussions. In this post I am listing my findings so far. I will be amending it as I gather more information.

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

On Mock Objects and Mocking

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.

Introduction

Collaboration Monitoring

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 Test-Driven Development (TDD)

Let me get one thing out of the way first: I am open to Test-Driven Development (TDD). I am not currently practicing it, because when I gave it a try some time ago it did not seem to work for me, but I do not have any objections to it in principle, so I might give it another try in the future. Let us just say that it was not love at first sight, but then again some relationships do take some time to warm up.

Having said that, let me now express a few reasons why I am skeptical of TDD. The previous paragraph should have established that I am not trashing TDD, I am just expressing some reservations.

So the "master" branch is not kosher anymore

The origins of the debate go so far back that they are lost in the mists of time, but a good starting point (which contains references to prior debate) is an Internet Draft from 2018 titled Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs. Some especially woke communities like the Python community had already started applying some of the recommendations in this draft as early as 2019, but things really picked up steam in 2020, with the murder of George Floyd.

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

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.