Testing – Test First is one of the most important and valuable practices in XP. It can increase the quality of the programme and can make other XP practices such as Refactoring, Collective Ownership and Continuous Integration work properly.
However, as mentioned in the last assignment, there was a problem with testing. Since the Email Visualisation is a project to create a user interface only without business logic, the only thing can be tested was Java Graphical User Interface (GUI) that is Swing. However, testing GUI is different from testing our actual programme as Java Swing is the part of Java Platform. It was, as stated in the last assignment, solved by the client as he gave the team the tasks which can be tested, yet as Andrew gave the team more idea of testing GUI, the team tried to test the GUI again. Firstly, it was found from the spike that even if the size of the certain GUI feature is set manually by the programme, it might not be applied to the GUI because the GUI is controlled by Swing itself. Therefore the team tried to test if the size of the certain feature is changed rather than checking the exact size of it. Thus, secondly team attempted to test Event Handler in order to test if anything is changed when a user click the text area in the window. However, another problem occurs when testing Event Handler. The Event Handler is inner class of the GUI component class which means it is invisible to the test programme which is outside the GUI component class. In order to solve this problem, the team consulted Andrew and the team could get the advice that the inner class which is Event Handler can be moved to outside GUI class only for testing purpose even though it is unlikely to happen. Therefore the team thirdly tried to test the Event Handler after move it outside the GUI class to make it visible to the test programme but there was another problem. The GUI class contains many other GUI components which are many text areas. These are primary object data members who are also invisible to outside the class, and the Event Handler uses those. Therefore the Event Handler has some errors as soon as it is moved out from the GUI class, as it uses variables in the GUI class. Finally the team realised it is not that easy matter to solve thus attempted to get proper information from the XP books, with regard to this kind of matter.
There is a good advice of testing in the book entitled ‘Extreme Programming Installed’. According to the book (p. 103, 2006), making GUI class with processing is not good. Thus we should not make GUI class with logic “other than the inherent event logic of press this” (Jeffries, Anderson & Hendrickson, 2006). Nevertheless the email visualisation programme GUI class still has just event logic; therefore Unit testing is still difficult. Thus the team decided to test the methods which belong to the email visualisation programme rather than the ones belonging to Java Swing in the class. Although the methods which totally belong to our programme are quite simple and there are not many of them, the team could practice testing first. In addition, as mentioned, as the client gave the testable tasks to the team, we could focus on that.
The new tasks which are testable were reading text file, containing many emails, and distinguishing each email to display it in different text area. For the purpose of doing this, firstly the team member had the meeting to simply design it. After discussion, it was found that Email class and the class which can contain many Email classes are necessary. There was also a need to have file reader which can read text files and create the instance of Email class based on the email text file. Secondly, the team started to code the test programme for Email class and EmailList class containing many Email objects. Those two classes are thirdly tested with the JUnit test case just created. There were at first some errors but we could know what the cause was and how to fix it based on the JUnit test case, then re-programme and re-test repeatedly until it passed all the test cases. Fourthly the test programme for file reader class is made then the team programmed file reader class. Finally the same processes which are testing and fixing the error are repeated then all the required classes are completed.
Nonetheless, unexpected result occurred during the run time after the programme has already passed all the test cases. In order to get the best practice to handle this kind of unexpected situation, the team read the XP Installed book again, and we could find the answer from the Chapter 13 Unit Tests page number 102. Jeffries, Anderson and Hendrickson (2006) say that “When the software gets an error in an acceptance test, it’s a sign tat a unit test was missing. Write that test then think about what it reminds you of.” From this, we could know we missed some test cases which can possibly break the programme thus we wrote the new test cases for the problems. After the programme passed all the test cases including the new one, we could see that problem has gone. We could also learn what kinds of test cases are necessary from that happening. As we practice test-first, we could learn more about it and could decrease the time to create test, the time to find the cause of the problem and the time to solve the problem.
However, as mentioned in the last assignment, there was a problem with testing. Since the Email Visualisation is a project to create a user interface only without business logic, the only thing can be tested was Java Graphical User Interface (GUI) that is Swing. However, testing GUI is different from testing our actual programme as Java Swing is the part of Java Platform. It was, as stated in the last assignment, solved by the client as he gave the team the tasks which can be tested, yet as Andrew gave the team more idea of testing GUI, the team tried to test the GUI again. Firstly, it was found from the spike that even if the size of the certain GUI feature is set manually by the programme, it might not be applied to the GUI because the GUI is controlled by Swing itself. Therefore the team tried to test if the size of the certain feature is changed rather than checking the exact size of it. Thus, secondly team attempted to test Event Handler in order to test if anything is changed when a user click the text area in the window. However, another problem occurs when testing Event Handler. The Event Handler is inner class of the GUI component class which means it is invisible to the test programme which is outside the GUI component class. In order to solve this problem, the team consulted Andrew and the team could get the advice that the inner class which is Event Handler can be moved to outside GUI class only for testing purpose even though it is unlikely to happen. Therefore the team thirdly tried to test the Event Handler after move it outside the GUI class to make it visible to the test programme but there was another problem. The GUI class contains many other GUI components which are many text areas. These are primary object data members who are also invisible to outside the class, and the Event Handler uses those. Therefore the Event Handler has some errors as soon as it is moved out from the GUI class, as it uses variables in the GUI class. Finally the team realised it is not that easy matter to solve thus attempted to get proper information from the XP books, with regard to this kind of matter.
There is a good advice of testing in the book entitled ‘Extreme Programming Installed’. According to the book (p. 103, 2006), making GUI class with processing is not good. Thus we should not make GUI class with logic “other than the inherent event logic of press this” (Jeffries, Anderson & Hendrickson, 2006). Nevertheless the email visualisation programme GUI class still has just event logic; therefore Unit testing is still difficult. Thus the team decided to test the methods which belong to the email visualisation programme rather than the ones belonging to Java Swing in the class. Although the methods which totally belong to our programme are quite simple and there are not many of them, the team could practice testing first. In addition, as mentioned, as the client gave the testable tasks to the team, we could focus on that.
The new tasks which are testable were reading text file, containing many emails, and distinguishing each email to display it in different text area. For the purpose of doing this, firstly the team member had the meeting to simply design it. After discussion, it was found that Email class and the class which can contain many Email classes are necessary. There was also a need to have file reader which can read text files and create the instance of Email class based on the email text file. Secondly, the team started to code the test programme for Email class and EmailList class containing many Email objects. Those two classes are thirdly tested with the JUnit test case just created. There were at first some errors but we could know what the cause was and how to fix it based on the JUnit test case, then re-programme and re-test repeatedly until it passed all the test cases. Fourthly the test programme for file reader class is made then the team programmed file reader class. Finally the same processes which are testing and fixing the error are repeated then all the required classes are completed.
Nonetheless, unexpected result occurred during the run time after the programme has already passed all the test cases. In order to get the best practice to handle this kind of unexpected situation, the team read the XP Installed book again, and we could find the answer from the Chapter 13 Unit Tests page number 102. Jeffries, Anderson and Hendrickson (2006) say that “When the software gets an error in an acceptance test, it’s a sign tat a unit test was missing. Write that test then think about what it reminds you of.” From this, we could know we missed some test cases which can possibly break the programme thus we wrote the new test cases for the problems. After the programme passed all the test cases including the new one, we could see that problem has gone. We could also learn what kinds of test cases are necessary from that happening. As we practice test-first, we could learn more about it and could decrease the time to create test, the time to find the cause of the problem and the time to solve the problem.
Finally we could learn that communication is important when practicing test-first. This communication does not only mean communication with only the other member of the pair but also all the programmers. Since if one creates a test case yet others do not know what it is about then other cannot programme properly. They may even remove it as they feel that is unnecessary. We had that one member removed one test programme as he thought it was not necessary yet it actually was. Once we had this experience we found that the communication is the most important thing in XP practices as almost all the XP practices depend on it.
No comments:
Post a Comment