Description

This repository contains tests for the frontend of the Relational Converter project. The frontend has a separate codebase here. These tests are written in Serenity BDD. It is an open-source library that simplifies writing automated acceptance and regression tests. It introduces the Screenplay pattern, which focuses on describing tests in terms of the tasks and interactions performed by actors, making the tests more readable and maintainable. This approach helps in creating more modular and reusable test components. Serenity BDD also provides detailed and informative reports, aiding in better understanding and tracking of test outcomes and ensuring higher quality in the development process.

This sample code demonstrates a test written using the Screenplay pattern in Serenity BDD. The test reads like a sentence, making it easy to understand and follow, which is a core principle of BDD.

@Test
public void savedQueryButton_clickingOnTheSavedQueryButton_replacesTheTextInTheInput() {
  givenThat(james).wasAbleTo(Open.browserOn(relationalConverterPage));

  when(james).attemptsTo(EnterAQuery.of("π_{surname}(A) ⋈ B")
    .then(SaveTheQuery.inTheTextInput())
    .then(ClearTheInput.text())
    .then(UseSavedQuery.number(1)));

  then(james).should(seeThat(theInputText(), is(equalTo("π_{surname}(A) ⋈ B"))));
}

SUT

The purpose of the application is to convert between two notations that are used to write queries in a formal query language called Relational Algebra (RA). Furthermore, the application can take any valid RA query and convert it into another formal query language called Tuple Relational Calculus (TRC).

Testing Framework

Selenium, Serenity BDD and JUnit5 were chosen. The plugin is set up in such a way that the command mvn clean verify generates a report in the target folder.

Testing strategy

My goal was to verify the correctness of every functionality depicted in the use case diagram. After all, the diagram shows every possible action user can take in the application.

Each use case was unit tested and some had additional coverage which is discussed in the following sections

Path based tests

For the path based tests there were only two sensible possibilities - notation conversion process and the conversion from RA into TRC. Since the application is pretty much linear, there is no branching and the diagrams are rather simple and quite literally straight forward.

The following diagram shows a conversion from the activity diagram into a correspondign decision graph with the generated TDLs on the right.

A decision graph for the conversion into TRC was made in a similar fashion.

Tests for both diagrams are located in src/test/java/tests/integration/pathbased.

Combination data

Combinatorial data were generated for the notation conversion process. The following table shows the possible combinations.

Notation	Schema	Semantic Checking	Formatting
Standard / Simplified	Correct / Incorrect	Enabled / Disabled	Enabled / Disabled

Mixed strength, pairwise and threeway combinations were generated by the ATCS software. For example, the pairwise:

STANDARD,CORRECT,false,false

SIMPLIFIED,CORRECT,true,true

STANDARD,INCORRECT,true,false

SIMPLIFIED,INCORRECT,false,true

STANDARD,EMPTY,true,true

SIMPLIFIED,EMPTY,false,false

Equivalence classes

As the application does not have any clear input field for which a discussion about equivalence classes would be feasible, an input regular expression for the relation declarations in the input schema panel was used.

Let IdentifierRegex := [a-zA-Z][a-zA-Z0-9_-]*. The regex used for table declarations is then defined by

^|(^${identifierRegex}\\(${identifierRegex}(,${identifierRegex})*\\)$)

The equivalence classes are

Identifier	Openning Parenthesis	First Inner Identifier	Comma
Correct / Incorrect / Missing	( / Another symbol / Missing	Correct / Incorrect / Missing	, / Another symbol / Missing

Another Identifier	Closing Parenthesis
Correct / Incorrect / Missing	( / Another symbol / Missing