Glossary of Terms

The purpose of this glossary is to ensure that the source code and the underlying documentation found on GitHub for Possum Labs YouTube tutorials are accessible and understandable. Prior to implementing Possum Labs solutions, we recommend that all viewers briefly review this glossary of terms to ensure clarity of meaning and usage in the context of Possum Labs solutions.

Possum Labs builds upon and develops with open source code. Our work relies upon relevant terminology; however, Possum Labs recognizes that domain-specific language may vary in particular to contexts. Furthermore, we acknowledge that the audience for our tutorials includes business analysts and other decision makers for whom we wish to make the language used as accessible as possible.

Most terms are derived from Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. It is recommended reading for developers, but when it comes to testing there is usually a much narrower set of concerns and options.

Using DSL to Create Meaningful Tests

The goal is to test an existing system, which we will consider to be our Bounded Context. From this context, we develop a DSL (Domain Specific Language) as our Ubiquitous Language. We will then take the names from the Bounded Context. We will use Model-Driven Design to provide a structure to this DSL by expressing Entities and access them through Repositories. We consider the interface (UI, API, Database, ESB) we interact with for these tests our Context Map, and we will insulate our tests using Anti-corruption Layer.

Bounded Context

The Bounded Context defines and bounds the particular system that we will test. In enterprise systems, it is often necessary to break large systems up into specific distinct contexts, because a single solution will not elegantly fit the whole system. It is the parts that we test, vs the parts we consider services and systems we depend upon.  

Context Map

Identifying the different interfaces that we will use to test the application and clarifying which systems or subsystems we will not be working with for this context. This delineation may include a range of range applications from UI (user interface), API (application program interface), ESB (enterprise service bus) to DB (database).

Domain Specific Language (DSL)

A particular purpose language, specific to a specific domain. We will be using Gherkin to facilitate the core structure of this language. This use will be different from general purpose languages like C#, Java or Javascript as there are many things that you will not be able to accomplish in this language; but it will be straightforward to achieve the task of manipulating the application we wish to test. Think of it as a garlic press vs. a knife, the knife can do much more, and the garlic press can’t do anything that the blade can’t do. However, when it comes to mincing garlic, the press is much easier to use if you have to do a lot of mincing.

Ubiquitous Language

A particular vocabulary tailored with consideration for the Bounded Context in which we intend to test an existing system. These are the terms that describe the business within which the application lives.

Model-Driven Design

In Model-Driven Design, the code and model remain tightly related with the function of keeping the code meaningful. We keep the model very literal to the business at hand so that it is easier to understand.


An entity is a representation of the system in testing, otherwise understood to be the core concepts that the system operates on.

Anti-corruption Layer

As the name implies, the anti-corruption layer is a form of protection or insulation that protects our activities from corruption from other aspects of the application(s) within which we work. Over time various aspects of most applications will change, in particular, most applications will evolve and are refactored. In testing, we likely have little influence over the core application, so instead, we must focus on insulating our work or bounded context from those changes by building a layer between us and the application under test. This focus means that if the application changes, we have to make fewer (if any) changes for the tests to change with it.


Possum Labs implements Gherkin because it is a Business Readable, Domain Specific Language that allows us to write documentation and automated tests in a manner that is meaningful to the organization and their customers. With Gherkin, we can describe a particular behavior of the software to a non-technical audience. Gherkin may be read using Cucumber or Specflow and mapped to other languages (Java, Ruby, Javascript, C#, etc.) for the test execution. An additional link to Gherkin at Github.

Want to know more? Visit GitHub for Possum Labs’ Documentation

%d bloggers like this: