Testing Unit For A Classcomponent

Testing has always been an important part of the software development. It is the last step of the software development and the step that decides whether the developed system will move to production. The entire system needs to be tested to make sure that it delivers the right results. The use of good modeling practices help to develop good quality software but it may not always avoid mistakes; they are inevitable and part of the process of developing software.

One of the challenges of designing independent components is making sure that they deliver the expected results. Independent components manifest their behavior when involved in a dialog with other components. The more complex the behavior of a component is, the more difficult it is to test. Testing, when done manually, is time consuming. There are several automatic testing methodologies that are successfully used in the software industry. One popular testing software application is JUnit (http://www.junit.org). In this book we will not describe in detail any of the existing testing methodologies. We recommend the readers to look for specialized books in testing methodologies. We will describe some simple testing "patterns" that can be used for testing classes or components.

One way of testing a class or a component in Java is to consider that class as a stand-alone one by adding a static main method and some logic for testing functionalities the class provides. Figure 9-5 shows an example of a main method and code for testing the behavior of class WeatherDataFromFile. In this case, we will make sure that the class WeatherDataFromFile we have developed provides the right daily weather data needed in the simulation process. The implementation in Java for this class is shown in Figure 8-35 in Section 10.3.1 of Chapter 8.

83 static void main(String args[]) {

84 Properties props = new Properties();

85 props.put("weatherFile,f,Mweather.txt,!);

86 WeatherDataFromFile weather = new WeatherDataFromFile();

87 System.out.println("----------Daily Weather Data-------------");

88 weather.initialize(props);

89 while (weather.hasNextQ) {

90 weather.next();

91 System, out. println(,fDayOfY ear^'+weather.getDayOfY ear() +" Tmin="+currentDay.getTemperatureMin()

+" Tmax="+currentDay.getTemperatureMax() +" Radiation="+currentDay.getSolarRadiation() +" Rainfall="+currentDay.getRainFall());

Figure 9-5. A testing unit for class WeatherDataFromFile (Part 2 of 2).

Line 83 shows the definition of the method as static and that does not return any results. Lines 84 and 85 create an instance of Properties class needed to store the name of the weather data file. Line 86 shows that an instance of the class WeatherDataFromFile, referred to as weather, is created. Line 87 prints the string "Daily Weather Data". Line 88 initializes the object weather using the parameter "weather.txt," which is the file name holding the weather data to be used in the simulation process. By definition, class WeatherDataFromFile implements interface Iterator. Therefore, it provides the means to iterate over the weather data. Line 89 tests whether the end of the file is reached. Line 90 obtains an object of type DailyWeatherData that is referenced by attribute currentDay. From the object currentDay, daily data can be obtained by sending messages such as getTemperatureMinQ, getTemperatureMaxQ, etc. Line 91 prints daily weather data for the current day.

Figure 9-6 shows a partial view of the weather data read from the file weather.txt. Notice that these results are the same as the ones shown in Figure 8-36. Therefore, class WeatherDataFromFile provides the expected results.

Daily Weather Data

DayOIYear=1 Tmin=5.1 Tmax=20.0 Radiation=4.4 Rainfall=23.9 DayOfYear=2 Tmin=10.8 Tmax=13.3 Radiation=1.1 Rainfall=0.0 DayO(Year=3 Tmin=12.1 Tmax=14.4 Radiation=1.1 RainfalhO.O DayOfYear=4 Tmin=3.6 Tmax=18.3 Radiation=6.1 Rainfall=14.7 DayOfYear=5 Tmin=12.8 Tmax=17.2 Radiation=5.6 Rainfall=0.8 DayOfYear=6 Tmin=12.4 Tmax=21.1 Radiation=5.0 Rainfall=0.0 DayOiYear=7 Tmin=11.1 Tmax=21.7 Radiation=7.2 Rainfall=0.0 DayOfYear=8 Tmin=12.0 Tmax=21.7 Radiation=8.3 RainfalhO.O DayOfYear=9 Tmin=6.1 Tmax=20.0 Radiation=8.3 Rainfall=0.0 DayOfYear=10 Tmin=3.5 Tmax=23.3 Radiation=11.1 Rainfall=3.8 DayOfYear=11 Tmin=13.5 Tmax=19.4 Radiatiori=2.8 Rainfall=0.0

Figure 9-6. Daily weather data obtained from the testing unit.

In a similar manner, we will create a testing unit for the class SimulationController. The class definition for SimulationController, as defined in Figure 8-39, will be provided with a static method referred to as main as shown in Figure 9-7.

Lines 72 through 75 define the parameters needed for the simulation process and assign them initial values. Usually, these values will be provided by users of the system. Line 76 obtains the unique instance of the SimulationController and line 77 sends simulator the message simulate with the appropriate parameters. The results of the simulation are stored in a Properties file by the simulator.

70 static void main(String args[]) {

71 Properties props = new Properties();

72 props.put("weatherFile","weather.txt");

73 props.put(MplantingDate,,,n 121");

74 props.put("soilDepth",ff145n);

75 props.put('1wiltingPointPercentf!,"0.06M);

76 SimulationController simulator = SimulationController.getInstance();

77 simulator, simulate(props);

78 System.out.println(,f-----Simulation Results-----ff);

79 Properties pr = simulator.getProperty();

80 Double rdweight = (Double)pr.get(MrootDryWeightM);

81 Double ptdweight - (Double)pr.get("totalPlantDry Weight");

82 Double fdweight = (Double)pr.get("fruitDryWeightM);

Figure 9-7. Test unit for class SimulationController (Part 1 of 2).

83 String matDay = pr.getProperty(MmaturityDayf!);

84 System.out.println(MRoot Dry Weight="+ rdweight.toString()

85 +" Maturity day="+ matDay

86 +" Total Plant Dry Weight=M+ptdweight.toString()

87 +" Fruit Dry Weight="+fdweight.toString());

Figure 9-7. Test unit for class SimulationController (Part 2 of 2).

Lines 80 through 83 read the results from the Properties file and lines 84 through 88 print the results. The obtained results can be evaluated by a specialist to make sure they are accurate, or they can be compared to results obtained with other versions of the software if they exist.

The ability to test independently class/components allows for a faster software development as the focus is on one class/component with a well-defined behavior. By integrating testing unit into the build process, it makes it easier to discover implementation errors and design flaws. A class that has successfully passed the individual test can be easily integrated into more complex testing scenarios where several classes/components are involved. Thus, using an iterative process that consists of testing individual classes and later the interaction of several classes, makes it easier to test complex software. We have used this approach all along the software development process and have obtained good results.

Chapter 10

0 0

Post a comment