Monday, February 11, 2013

This Bugs Me

Let me talk about my first bug in Obsidian, but first let me explain what the PackageEqualityMethod is and why it is important.

PackageEqualityMethod is a class generated when creating the framework for testing. It holds equality methods for all the classes in the package that the test engineer will then be able to modify to allow non-primitive classes to have a isEqual method that we then use to check for equality. Normally a test engineer needs to write these out for each class if it is needed, however Obsidian takes care of this by having three levels of equality checking. A GlobalEqualityMethod is currently being developed that will have equality methods for every class in the project. This will be the main location where test engineers put most of their work. Below that is the PackagEqualityMethod. The package equality will by default call the global equality, but if needed the test engineer can go in and change the way equality is checked for that specific package. The third level is at the individual class. This equality method will by default use the package equality methods (which in turn may be using the global if it has not been modified), but can also be modified to test for equality in a different way for just that class.

Currently the issue tasked to me is Issue 6. Issue 6 deals with the building of the PackageEqualityMethods and it missing required import statements. I have been studying the errors with a few open source projects and it appears to be an issue with Nested Classes. The way I found this out was by running obsidian with the  different open source projects and manually fixing the errors. When I fixed the errors I went into the offending class that was not being imported and discovered that all of them had to do with being nested classes and in certain conditions Enum's. While one of the projects I tested had a lot of nested classes inside, most of them were not accessible outside that class (most were private). The reason for the errors was that Obsidian was trying to make an equality method for that class without importing it specifically. An example of a class that produces the bug follows:


 public class Foo{
 private int x;

 public method1(){
 //Do stuff
 }

 public class Bar{private int y;
  private method2(){
  //Do stuff
  }
 }
}

This creates a problem whenever Obsidian creates the equality methods because in the PackageEqualityMethod it does not "import com.foo.bar", it only imports "com.foo". It also creates a problem when two nested enum classes are put into the PackageEqualityMethod. I am currently working on how to change the import creation, but depending on what the group thinks I might change the way Obsidian creates the equality methods to ignore nested classes. The second option feels more like a cheap way of fixing the problem while also hindering the test engineer. If the code has a public nested class you should test it separately as if it was another class.

No comments:

Post a Comment