Testana: A better way of running tests

Abstract:

A software testing tool is presented, which uses dependency analysis to greatly optimize the process of running tests.

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.

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.

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.

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

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.

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.

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.

Object Lifetime Awareness

The Thinker (French: Le Penseur) by Auguste Rodin (From Wikipedia)

Abstract

Garbage collectors have given us a false sense of security with respect to what happens to an object once we stop thinking about it. The assumption is that it will be magically taken care of, but this does not always go as hoped, resulting in memory leaks and bugs due to failure to perform necessary cleanup. Tools for troubleshooting such problems are scarce, and not particularly helpful, so finding and fixing such problems is notoriously difficult. 

A methodology is presented, which differs from current widespread practices, for maintaining awareness of, and exercising full deterministic control over, the lifetime of certain objects in a garbage-collected environment. We issue hard errors in the event of misuse, and accurate diagnostic messages in the event of omissions, thus improving the robustness of software and lessening the troubleshooting burden.

Coherence: The Assertable Lock

Abstract

A Software Design Pattern for concurrent systems which makes race conditions something that can be asserted against and thus deterministically eliminated rather than stochastically reduced or minimized. (Subject, of course, to the thoroughness of the assertions.)

Image by reginasphotos from pixabay.com

A description of the problem

Every Software Engineer who has dealt with concurrency knows that it is hard. The bane of concurrency is race conditions: when a thread accesses data without taking into account the fact that the data is shared with other concurrently running threads which may alter that data at any unforeseeable moment in time.