Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Similarity checking tests for the old version of FirstInstance (with SimilarityChecker) #13

Open
wants to merge 79 commits into
base: build-pipeline
Choose a base branch
from

Conversation

AlpTorac
Copy link
Contributor

@AlpTorac AlpTorac commented Oct 28, 2024

Introduction

Using the initialisers introduced in #12, this pull request introduces a large amount of unit tests focusing on verifying the similarity checking process within the FirstInstance. The aim is to supplement the tests within "cipm.consistency.vsum.test" with lightweight tests that can help pinpoint issues regarding the similarity checking.

The contribution of this pull request is a plug-in called "fitests", which contains the said tests.

Note 1: This pull request contains the pull request for initialisers too (#12), because it was not possible to create a stacked pull request from the CIPM fork.

Note 2: Some of the tests are disabled, due to Null Pointer Exceptions (NPEs) they throw. These NPEs are addressed in (#10, which builds upon #9). The disabled tests will be re-enabled in the upcoming pull request (#14) for the new version of FirstInstance.

Note 3: If an initialiser has an adaptation present, only its adapted version is used in the parameterised tests, due to NPEs from Note 2. Likewise, this will also be addressed in the upcoming pull request (same as the one from Note 2, #14).

About the structure of fitests

The "fitests" plug-in is structured in a way that minimises dependencies to outside plug-ins. To this end, there are several abstract test classes that extend one another. This way, many different parts of this plug-in can be re-used in the future to implement further tests.

Currently, all test classes extend the abstract test class for JaMoPP, as it is currently the only technology under test within this plug-in.

About the unit tests

The fitests plug-in introduces many unit tests, in order to cover as much of the similarity checking process as possible. Inside the said tests, various JaMoPP objects are mostly constructed programmatically, which means that no actual Java project is parsed. The reason behind this is to keep project parsing of JaMoPP separated from the similarity checking introduced in CIPM. That way, problems with parsing do not affect the outcome of the tests.

Different kinds of unit tests are introduced below, in their corresponding section.

Interface tests

The "cipm.consistency.fitests.similarity.jamopp.unittests.interfacetests" folder contains parameterised unit tests for JaMoPP objects' mutual aspects (i.e. capabilities they get from mutually implemented interfaces). These tests are parameterised over initialisers (see #12 for more information).

Future note: If certain aspects in certain types of JaMoPP objects behave in such differing ways that they have to be tested separately, they should be separated from interface tests and be implemented as implementation tests.

Implementation tests

The "cipm.consistency.fitests.similarity.jamopp.unittests.impltests" folder contains unit tests for JaMoPP objects' unique aspects, such as their unique attributes, which only singular JaMoPP objects have. Implementation tests are currently not parameterised over initialisers, as they only consider one type of JaMoPP object each.

Complex tests

While interface tests and implementation tests only consider certain aspects of certain JaMoPP objects in an isolated fashion, the tests under "cipm.consistency.fitests.similarity.jamopp.unittests.complextests" construct more advanced JaMoPP objects. This includes JaMoPP objects, which contain other JaMoPP objects that have to be set-up in certain ways.

Complex tests are separated from the rest of the tests, because the construction of individual JaMoPP objects becomes important and using initialiser adaptation strategies makes understanding the construction process harder.

Other tests

The "fitests" plug-in additionally introduces other unit tests:

  • GeneralJaMoPPSimilarityTest: Tests the (general) control flow of the similarity checking process, while abstracting away from the concrete JaMoPP object type as much as possible.

  • SPLevoModelsSimilarityTest: Tests the similarity checking process by parsing some minimal Java projects under "splevo-testmodels". This is the only test class introduced here, where JaMoPP is used to parse Java projects.

  • UtilityTests: Serves as a "meta-test" for the tests within "fitests". Ensures that initialisers of all JaMoPP objects are accessible from tests and that each JaMoPP object has a corresponding test file.

The abstract class encapsulates the logic behind storing adaptation
strategies for initialisers
Initialiser packages (IInitialiserPackage implementors) can be used to
grant centralised access to related groups of initialisers. They mimic
org.emftext.language.java.JavaPackage and allow package-based access to
initialisers. The content of initialiser packages is to be defined by
overriding certain methods (refer to the documentation within the
IInitialiserPackage interface).
for Java-related classes (all of them extend EObject) used by JaMoPP.
The main purpose of this interface is to make it easier to declare
methods for the said classes.

This interface can also be used to filter JaMoPP-related initialisers
from EObject initialisers, if initialisers for other EObject utilising
techologies are implemented in the future.
org.emftext.language.java.classifiers
org.emftext.language.java.containers
org.emftext.language.java.expressions
org.emftext.language.java.generics
org.emftext.language.java.instantiations
org.emftext.language.java.literals
org.emftext.language.java.members
org.emftext.language.java.modules
org.emftext.language.java.parameters
org.emftext.language.java.references
org.emftext.language.java.statements
These strategies can be used to adapt the initialisers, so that they can
successfully initialise the objects they create within tests (to be
implemented in another plug-in in the future).
Serves as a facade to some EcoreUtil methods

Provides the means to clone EObject instances along with their container
for tests that work with Resource instances
Implementors of this interface can be used by tests to have centralised
access to various expected similarity checking results.
This abstract class, along with the interface it extends, provides the
implementation of a storage for expected similarity values.
Implementors of this interface encapsulate the means to adapt
collections of initialisers. They can be used by parameterised tests to
include adapted versions of initialisers.
Implementors of this interface can be used by parameterised tests as a
source of initialisers.
This singleton helps keep expected similarity values as well as
initialiser parameters consistent across tests
for tests that work with EObject instances.

This extension provides various methods that can be used in tests to
perform similarity checking. It also integrates
InitialiserTestSettingsProvider.
for JaMoPP-related initialisers
for JaMoPP-related similarity checking tests
for JaMoPP-related similarity checking tests
for JaMoPP-related similarity checking tests

Integrates Java similarity checker

Provides static methods for retrieving certain groups of initialisers in
similarity checking tests. They can be used within static methods of the
said tests as MethodSources.
for JaMoPP-related similarity checking tests

These interfaces provide the means to quickly create certain JaMoPP
objects in form of default methods. They can be implemented by the
concrete tests.
Each of these tests are implicitly parameterised over certain JaMoPP
objects via the initialiser parameters they take. This way, they spare
large amounts of code duplication, because otherwise one would need to
separately implement many test methods for each JaMoPP object.

These tests isolate certain aspects of JaMoPP objects, such as certain
attributes they have, and verify that similarity checker correctly
assesses their similarity.

Disabled null check tests in interfacetests till NPEs are fixed

Use adapted initialisers in some interfacetests till NPEs are fixed
These tests isolate certain aspects of JaMoPP objects, such as certain
attributes they have, and verify that similarity checker correctly
assesses their similarity.

Some tests are disabled till null pointer exceptions are fixed.

NewConstructorCallTest is adapted till null pointer exceptions are fixed.
These tests aim to verify similarity checking of JaMoPP objects, whose
construction is not as simple as those from "impltests" and
"interfacetests".

The cases addressed in these tests were separated from "impltests",
because they each require a complicated setup, in order to cover certain
branches of the similarity checking logic.

IdentifierReferenceContainerTest is disabled till NPEs are fixed.
It ensures that each JaMoPP object has a test class (as a Java source
file) and that the initialiser of each JaMoPP object type can be
accessed from tests.

Adding such a meta-test was necessary, due to the vast number of JaMoPP
object types and their complicated type hierarchy.
This test class focuses on testing the control flow of the similarity
checking process at a high-level. This way, it covers some edge cases
that are not addressed in the "unittests".

Some general tests are disabled till NPEs are fixed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant