Testing - Test Fist

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.

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.

Coding Standard

Coding Standard
There are certain benefits from having a coding standard. If every programmer follows one agreed coding standard, including indentation, capitalisation, names and so on, it can improve programming speed and help the programmers communicate with each other. They also can focus on the real issues rather than focus on reformatting others' code to make it understandable.

What we've done.
There are mainly two ways, used to practice coding standard. The first one is that one agreed coding standard was made at the beginning of the project. To make the coding standard, well-known coding standards, namely Java and PHP coding standards, are examined. Thus everyone knows what to follow when they code and decide the variable names. It can also make one’s code easy to understand so when another person tried to modify other’s code, there was no problem caused by difference of each code. The second way is using code formatting function in Eclipse. At the beginning of the project, everyone import one agreed standard configuration file for Eclipse to one another’s Eclipse. Therefore, when any one had any problem with formatting, it could easily be solved by implementing code formatting function in Eclipse.

Any problems?

There was no serious issue with coding standard as one agreed standard was made at the beginning of project. The minor one is that every one needed time to get used to the coding standard. That small problem of getting used to the coding standard could be solved with checking the coding standard document, and more easily that was solved by using Eclipse code formatting function. If anyone was not sure whether he / she was following the right coding standard or not, only using code formatting function was required to ensure that the right coding standard is being followed.

Reflection

Reflection
Before I started this subject, I had a little knowledge about it from other subjects namely Project Management and Quality Assurance (PMQA), and Information System Development Approaches (ISDA). When I chose it, I expected to learn about and practice all the good features in XP. These may include Test-First and Pair Programming. However there was a problem with test-first as the project we were assigned was developing GUI only. Thus it was hard to practice that test-first yet it was not bad as I could think about how to solve this kind of problem. Therefore when I have this problem again I would not need to repeat all the processes that I have already attempted to solve the problem. I could also learn from the XP book that GUI classes should not have logic method inside it.

Although there was initially a problem with the testing, I could practice test-first later and now can feel how good it is. I actually stated to use this practice in another project of mine once I practiced it in XP subject and felt the value of it. It actually improves the quality of my programme, and I can also easily maintain the programme since I have all the test cases, so I just need to test all of them after I change anything. Testing practice might be considered as waste of time but it is actually not. I can feel it is indeed worthwhile. I especially like the xUnit test programme that allows me to save the time to create test programme and the time to test.

Another thing that I like in this subject is a communication. Like other projects, the communication is a very important factor, yet it is extremely important in XP since it requires two programmers to code together with sharing one computer and there is no one who owns any specific code. Two people work together and everyone can change any code made by any person, so the failure of the communication can be the disaster of the project. As XP requires more communication than other projects it might strengthen the relationships among the members and all the members can easily understand each other. Thus the team can improve the quality of the product. From the XP, I could feel that it is very important and could learn more how to interact and communicate with others. If I have XP project or other systems development methodologies in IT industry, I think I can handle the problem may occur during the project, because I could experienced many problems and could practice many things and how to find the solution in this subject.

I could also learn about many good applications and tools such as SVN and JUnit. Those things are the ones I knew before but did not have a chance to use. In XP, I could use both and found the convenience of those. I will definitely use those when I do other projects in the future as now I can feel that those tools can improve not only my productivity but also the quality of my product. I am in fact using JUnit now in another project.

Test First

Test First

Test first which means the test are created before starting coding can guide programmers to making the right code. First, with all those tests, the programmers can know what functions they need to make. They can also know whether their programme fulfils the requirements or not. They can code the programme to make it pass each test, and passing all the tests means completion of the software. It can also help to check if any changes, made after the programme is passed the tests, cause any problems or unforeseen results. The test first can be done by xUnit test case programme, and in the case of email visualisation, it is JUnit which is unit test case programme for Java.

What we've done.
JUnit and Eclipse were used to practice Test First practice. JUnit, one of xUnit, is a testing tool which is for free. xUnit is recommended tool by Jeffries, Anderson & Hendrickson who are the authors of the book, “Extreme Programming Installed”. With JUnit and Eclipse, it was easy to conduct unit test. Firstly, the test case code was written with JUnit, then, for example, around 10 errors were showed. Based on the error messages and test programme, the actual Java class for the application was coded. The pair programmers started to code to pass each test one by one. The programme could eventually pass every test. Once it is done and as other test cases are required, more test cases with JUnit were created. Now it is in progress.

The Problem we've faced.

There was initially problem with unit test. Since the project is visualisation and developing Graphical User Interface (GUI), it is hard to test. It might require more time on making test programme then the time spent on developing the application. The problem was solved by the clients as they assign more tasks, which can be tested such as data handling, to the team. Once the clients asked the team to make that, unit test was done through JUnit test and Eclipse, as mentioned.

The problem...

In week 5, we tried to practice pair programming. As some of us had already got the development environment set, they were ready to do, while some didn’t as they were still waiting for more space from FIT. Thus first of all the prepared pair started to programme together. After around 10 minutes, we found a problem. That wasn’t really the problem of pair programme, but it was very general one as any project can have. The problem was that no one is familiar with Java Swing, which is major API to develop Java Window application. Therefore, instead of doing pair programming, we started doing spike. Spike is also one of good features from XP. It is trying to code in quick and dirty way in order to find the solution of the problem. However, we couldn’t even start spiking as already mentioned we had absolutely no idea about Swing, so we actually spent much time on researching first. We could eventually do some spike yet it was not enough to get the result. Thus after the first pair programming we couldn’t get any satisfactory result. In the second meeting of the same week, we could get the windows displaying many text areas yet it was actually the result form the spike. We could anyway have the programme to show the client yet it wasn’t so good. Thus we all agreed to research until the next meeting.