Line 9: Squashed?

Since last week we have all made progress on our assigned bugs. We should each have at least one ready to commit to the repository on Wednesday at 6:30. Working in Obsidian has made me much more comfortable with the program, and I am beginning to gain insight into how to work with it. My terminology could still use a little work, and I am hesitant to write any official documentation for the project without first running it by Hunter, but I am getting there. That is the important bit.

My bug was to come up with a more comprehensive method for naming method tests, and classes that Obsidian has to create. Formerly, the code was just appending Test to the end of these things; however, this was dangerous because of the frequency with which programmers write test classes with exactly that naming scheme. This would cause Obsidian to confuse itself when it was searching for something like ClassTest.java for instance. The actual test class for this would be called ClassTestTest.java which would not be what Obsidian was looking for. This is a pretty simple fix, but it is an important one none the less.

We came up with a few different ways of naming method tests, but as of yet we have no clever implementation for the Class tests. At first, we were going to name a method following a method that reflected its arguments. For instance, add(int i, int x, String s) would become addTwoIntOneString() when Obsidian had created the tests for it. This has the benefit of creating distinct method signatures for overloaded classes, but we ultimately shied away from this approach. Some members of our team felt that the method names might become too long this way, and opted for a simpler approach.

 The new method that we finally agreed on was much simpler. It takes any method name, and basically creates a test method that looks like this Test_<methodName>_#. The number will only appear if the method is overloaded, and from there it increments upwards. In order to make a more distinct link between these generic method names and the methods they originated from, Laryea has agreed to write some code to put a comment before each test method that will name its "parent" method.

This weekend also saw a large expansion in our Google Code Wiki's functionality. We planned out the basic structure last week, and over the weekend I created most of the pages and added information where I could. It also has a navigation bar now, which makes navigating the pages much more convenient. It is really coming along, and it will only get better from here forward.

One slight problem that I had during the creation of the wiki was the state of JUnit. The project seems to be migrating, and their home page is looking quite unimpressive at the moment. They also seem to have removed their source code from where it was being hosted. This was bothersome because it would have been nice to link them on the wiki. We decided to wait a week or so and see if they get it back up before we link to it though.