Where is that missing semicolon…

Leave a comment

Intermission: Wrapping up our work with Trunk-248

As the group finishes work on Trunk-248 we plan to do submit our commit to the Open MRS core as it has been established all we were required to do was replace any //TODO junit  comments with the correct //@should annotations so that the MRS team can use their build in plug-in to find and help implement the correct JUnit testing. 

All and all, and even after some confusion on the matter, we only found a couple handfuls that needed to be replaced.  Since the group is now quite familiar with JUnit, we are planning to find another ticket regarding the same matter. Most likely a follow-up ticket regarding the actual implementation of the JUnit testings at our @should annotations.  Thanks to several sources, we have a few guides and readings on how to go about doing this, as well as reference material on how exactly to accomplish them, such as Vogella’s Guide.

However, despite our plans to move on to our next ticket, that does not mean we are entirely completed with our Trunk-248 ticket.  After submission, our code and changes must go through a series of (hopefully) brief review.  Should whomever choose that we need to reiterate our group commit, then we must go back and make necessary changes, putting a temporary hold on our next Ticket.  Not to say that we are in limbo, but with a final commit about to happen, we don’t have enough work to do on this current ticket unless something went horribly amiss. 

Leave a comment

Digging through to place more @Should JUnits…

It appears that now most of the @TODO junit testings have been found in the sections of code we have dug through, although the group  believes there are still plenty more to find in areas we haven’t quite searched through.  There is some vague parameters with TRUNK-238 such as how far do we need to go with the JUnit testing?  Do we simply need to go through the entirety of the code and find all the @TODO’s or even more so, do we have to specify and begin implemntation of the JUnit tests? 

I was under the assumption that we only need to locate the @TODO’s and replace them with the @SHOULD JUnit test comments so that the other tickets regarding implementation of the JUnit testing would then have and know what to implement.  We will have to have another group meeting shortly through IRC and contact Ben Wolfe on the matter, since he is the guy who created then reopened the ticket for us.


Much more work to do, although it seems we are getting closer to finalizing the initial job of adding the JUnit comments in where they need to be.

Leave a comment

More work with JUnit testing

After reading through some more segments of code that needed JUnit testing, I had to again re-read up on JUnit testing to make sure my comments were accurate.  Our ticket is an ongoing process of finding out where specific JUnit tests need to happen, and more or less mark where with code.  However, I realized about halfway through that I was marking them incorrectly, and had to go back and correct my statements I had made.  I could only imagine the headache of the second part of this ticket (which is actually implementing the JUnits tests) just to realize the comments put in place were asking to test the wrong things.  Nothing beats doing the same work twice because of lack of understanding.  Also, on that note, I need to find a better way to scan through all the files in eclipse to find those //TODO JUnits

Also, besides reading up again on JUnits (and here) to more understand how they work and the correct format of them, I also read up on this article (OpenMRS starter guide, provided by Prof. Wurst) to more familiarize myself with OpenMRS and more specifically the tutorials regarding GIT. More group updates to come as we continue to scan through the code and add appropriate comments.

Leave a comment

Quick Update, Trunk-248

Well, after a bit of confusion and attempted contact with Ben Wolfe, our ticket has reopened and Dhimitris has successfully reclaimed it.
Work this week has started up again, digging through the code and searching for locations where new JUnit testing needs to be accomplished.   Due to the nature of this ticket, ongoing work has been completed since 2008, so there are many chunks of code from the OpenMRScore that either already have fully functional JUnit tests implemented or comments describing what type of JUnit tests need to be done.

As of now, all three of us got back up to speed, reforked the code and got the latest version of Maven installed through the Eclipse marketplace. Still trying to figure out how to divvy up the workload between ourselves and what parts of the code to assign and report on with the CS-401 wiki page.

More updates soon as we get back to scanning through the code…

Leave a comment

Ticket Close Confusion, Junit Annotations

Well, to start things off after getting both my laptop and computer at home all setup working with github, my first goal was to read up and become much more familiar with JUnit.  The Ticket my group is working (TRUNK-248) requires us to go through the selected sections of code and simply add “@should” annotations where they were required.  A relatively simple task of reading through code to allow other users to scan through and identify where JUnit tests need to happen.

Just for a brief explanation on what JUnit testing is, it is essentially a small chunk of code to ensure that another chunk of code operates and functions as intended. More specifically, there are several types of tests, all using assert statements such as “assertTrue([message], boolean condition)”, “assertSame([String], expected, actual)” and the like. 

To actually perform these tests, JUnit must be downloaded and ran with a java text editor such as Ecplise.  While eclipse may not be essential to performing or coding these tests, Ecplise does contain several built in tools to perform JUnit testing — which makes everything a lot more convenient. 

However,  due to some confusion regarding this ticket, it has been deemed as closed.  The ticket’s Status is still labeled as “In Progress” and an Resolution of “unresolved”.  Having known this, we as a group would not have chosen to work on it in the first place.  A new ticket will have to be found and worked on asap as to not get behind on work.  The good news is, it still gave us an excuse to look through the code, which is something.