Unit Test: @should annotations

Basically what I’ve been doing is introducing the “@should” javadoc annotation. Each api method will get one or more @should annotations that simply state a behavior of that method need testing, in other words, each @should annotations should be phrased. For instance:

  • @should not fail given null parameter
  • @should return empty list if no results

The example above would become unit test named (given the method was findPatient):

  • public void findPatient_shouldNotFailGivenNullParameter()
  • public void findPatient_shouldReturnEmptyListIfNoResults()

These are the step I followed to get started on this task:

  • Import the OpenMRS-core Repository from Eclipse
      • In Eclipse, choose File:Import
      • Choose Git: Projects from Git
      • Select Repository Source: URI
      • Browse the location of the local file on the PC (file: openmrs-core)
      • Select the master branch
      • Choose the directory you want to clone into
      • Select Use the New Project Wizard
      • Choose Java: Java Project
      • Enter a project name (To get all files imported, the given name has to be exactly the same as the local file name. In this case the project name should be: openmrs-core)
  •  Start searching all methods that do not have tests
      • In Git Bash, type command:  $grep –r ‘@should’ openmrs-core  (This command line will recurs into sub-directories to look for all “@should” instances)
      • Command:  $grep –r ‘@should’ openmrs-core > file.txt   (This line will save the output to a file text)
  • Browse ‘@should’ annotations in the packages  
      • The txt.file will output all packages that still have ‘@should’ annotations.
      • In Eclipse, look for such packages and start modifying them, so those methods become unit test names.
      • For example: /api/src/main/java/org/openmrs/somepackage/SomeObject.java:

In Eclipse: /api/src/main/java/org/openmrs/aop/AuthorizationAdvice.java:


Unit Testing

As a group we continue working and trying to find more detailed information about the assigned ticket. Unfortunately, the lack of communication and responses from the developers is limiting the progress of our project.

Last week, we did the JUnit Lab in class, which was very helpful in understanding how unit testing works. I had to install GitHub in my laptop to be able to open git files in Eclipse. To start working on the Lab, I had to fork JUnit-Lab Repository to my account and then I cloned it from Eclipse.

After going through and finish the lab, I tried to follow the same steps with the OpenMRS-core Repository. I ran into problems, but after so many attempts I finally got to clone the repository by importing the project from a local source. 

New Ticket: TRUNK-243

After two attempts to work on the OpenMRS’s project my group has now chosen a new ticket, the TRUNK-243. The description of this ticket explains that the current unit tests have bad names, so this ticket is about cleaning the unit test. I’ve been researching about unit test before to start working on the actual code, so this is what I have learned this week.

What is Unit Test?

Unit testing is a software development process designed to correct individual parts of code by isolating each part of the program. In other words, unit test is a piece of code that invokes a unit of work in the system and then checks a single assumption about the behavior of that unit of work.

Benefits of Unit Testing

  • Reduces the level of bugs in production code
  • Problems can be found early in the development cycle
  • Automated tests can be run as frequently as required
  • Facilitates change
  • Simplifies integration
  • Is a form of documentation
  • Can improves the design of code