CAIS - Comparative Anatomy Information System for the Foundational Model of Anatomy (FMA) and the Mouse Anatomy Ontology (MOA)

Test classes explanation

The test classes

The knowledgebase currently contains a class called "Test" which is a subclass of the class "Physical Anatomical Entity". I created the "Test" class and its subclasses in order to be able to test the functionality of the application, because the knowledgebase currently does not contain enough anatomical information about the human and the mouse to enable thorough testing.

The test classes are by no means exhaustive, and I am convinced that more comprehensive testing will be required before we can be satisfied that the application executes as we need it to. The test classes are really simple and I include them mostly as an example of the application's functionality. Here are some brief explanations about how I used the test cases:

1. Query type: shared and not shared
The query type shared is supposed to check the parts of the two selected structures and show the user which parts map to each other. The query type not shared is the complement of shared and shows the user the parts that one structure has that do not map to any of the other structure, and vice versa.

You can perform the shared query with Test 1 and Test 2. The results should tell you that Test 1 has a part called "Part 1 of test 1" that maps to the part of Test 2 called "Part 1 of test 2"., which is what happens if you actually execute the query.

If you perform the not shared query with Test 1 and Test 2, the results should tell you that "part 2 of test 1" and "part 3 of test 1" are parts of Test 1 that do not map to any parts of Test 2. Also, "part 2 of test 2" is a part of Test 2 that does not map to any parts of Test 1. If you actually execute the query, you will see that the correct results are displayed.

If you increase the recursion level to 1 or 2, you will see that the query is executed down the specified number of levels of the part hierarchy.

2. The subject and object are both sets
I wanted to make sure the application behaves correctly when both the structures in the query are anatomical sets (This mostly concerns the query types similar to and differs from because sets do not have parts so, currently, the shared and not shared query types are not very useful). I made two test sets, called Test 3 and Test 4. The application is supposed to take the members of each set and perform the query with each of the members, which is what happens if you execute the similar to or differs from query with these test classes.

3. Either the subject or the object is a member of a set that maps to the other structure
The way the knowledgebase is currently implemented, if a set maps to a structure in another species, the members of the set do not map to the same structure. But if a user performs the query with a member of a set and a structure, and the set maps to that structure, then we want to make the user aware of that fact so that he/she can perform their query with the set and the structure. For example, if the user performs the query "Member 1 of test 3 similar to Test 4" then we include a note that tells the user that "Member 1 of test 3" is a member of Test 3 and that Test 3 maps to Test 4, therefore he/she should try the query "Test 3 similar to Test 4".

These are some of the instances where I found the test cases helpful. I am not sure why I included the test classes "Set containing test 4" and Test 5, but I will leave them in there in case I remember later or find a user for them.

More test classes can be added as necessary, and the current test classes can be removed if they are no longer need.