-
Notifications
You must be signed in to change notification settings - Fork 6
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
AlpTorac
wants to merge
79
commits into
CIPM-tools:build-pipeline
Choose a base branch
from
AlpTorac:fitests-oldsc-pull-req
base: build-pipeline
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Similarity checking tests for the old version of FirstInstance (with SimilarityChecker) #13
AlpTorac
wants to merge
79
commits into
CIPM-tools:build-pipeline
from
AlpTorac:fitests-oldsc-pull-req
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.