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.

Week 3 & 4

I was too busy to write anything here.

In the week3, customers were introduced, and we handed in the preferences of the projects. After the introduction, we practiced planning game with trump cards. It was very interesting. We estimated the time to finish tasks on the several sheets of paper. The tasks were about sorting the cards. After estimation, we chose one of the tasks and did that within the given time. We did this game twice, and in the name of common sense, the estimation of the second time is supposed to be more accurate, yet the first estimation was more accurate. I think it's because we had more experience of doing those tasks after did some of them, so we could finish earlier than what we expected. It was a learning curve effect indeed. However, in the second estimation, we just estimated without consideration of that improvement of our performance.

On the weekend, we got the customer allocation email from Andrew. I expected some web application development but the project we have is developing window application in Java environment. We actually have a little problem with that as none of us are familiar with Java Swing which is Java Window API. Thus, we tried to research about it and found some Swing books to read.


In the week4, we had the first customer meeting. Our customer is Alastair who is a very kind and nice man and also a software developer. We had misunderstanding about meeting day so had to change the meeting day twice. Despite this annoying situation he understood us and accepted those changes. After this experience, we made sure about the fixed meeting time which is agreed with all the members and the customer.

In the meeting, before we started to do planning game as we learnt, we talk with our customer to get very general information and overview of the project. After that, we explained about the planning game to our customer. As we already practiced planning game, it was not difficult to do it. We could easily do with giving some examples to our customer. Besides, he has some knowledge of XP, so it was also helpful to work with him. We helped him to decide the functions that the software shall have and to subdivide them.

After the planning game, we estimated the time to develop each task, then showed the cards with the estimated time to the client, and asked him to choose one of them which he wants to have first. We have 11 cards from him, and he first chose "Display all the message in a window". The estimated time for this function was 7 hours.

The Second Lecture (2007-08-10)

In the second lecture last Friday, we learnt how XP project is processed and more details about planning game.

After the lecture, we made up a team and practiced planning game. During the game, some questions occurred.

"Do we need to wait until the customer finish writing story cards?"

- No, we need to communicate with the customer to help him/her to write the story cards better.

"Should we estimate the time to develop a function in front of the customer?"

Yes, as communication is very important to have a good agreement between the customers and developers, we need to do that in front of the customers in order to communicate with them.

I would really like to meet customers and start a project as soon as possible, on the other hand I'm a little bit worrying that I have not only one group work and project. The other subjects are also project subject. Furthermore, I also work and all those things make me anxious. However, I believe I can do it and I'll make it!

After the First Lecture (2007-08-03)

After the First Lecture (2007-08-03)

(I copied this post from one of my posts on my uni blog.)

Today I had the first lecture of eXtreme Programming (XP). I'd like to be a good programmer and a good developer so chose this subject.

I have a little knowledge of system development from my work experience and Systems Development Project (SDP) subject. In the SDP, I practiced waterfall model so it wasn't related to XP. In my work, there are several methodologies, used to support system development such as incremental development and time boxing from Rapid Application Development as well as some features from XP. However, just some features of XP are used thus I don't really know about XP.

XP is the one most prominent methodology of agile methodologies. It is, according to Avison and Fitzgerald (2006), used to support quicker development for small and medium size system and application development. They also affirm that XP is more rapid in software development than step-by-step methodology such as waterfall model. In XP, there are often customer meetings to get user requirements and to apply immediately these into the system development, thus it can guarantee the certain level of quality.

In the today's lecture, I learnt the values and the practices that XP has.

There are 4 values of XP which are:

1. Simplicity
2. Communication
3. Feedback
4. Courage

and 12 practices which are:

1. The Planning Game
2. On-site Customer
3. Small Releases
4. Simple Design
5. Pair Programming
6. Testing - Test First
7. Refactoring
8. Collective Ownership
9. Coding Standards
10. Continuous Integration
11. 40 Hour Week
12. Metaphor

The followings are what I've understood from the lecture.

■ XP Values

• Simplicity: choosing simple design, and small release can produce the system quickly with satisfying the customers' requirements for the current iteration of the project.

• Communication: good communication through the pair programming and frequent customer meetings can deliver a good result.

• Feedback: From testing, customer meetings & stories, pair programming and small timeboxes to repleat project process, enough feedback can be gained to improve the quality of the system.

• Courage: When it is certain that the changes made by a programmer do not bring about some unexpected problems, the programmer can be confident to refactor and redesign the system to make it better (Testing can be the key of this).

■ XP Practices

• The Planning Game: At the beginning of the project, customers write what functionalities they want the system to have on the 'story cards' then developers and programmers estimate the time required to make each function, and write it down on each card. After that, the customers choose the cards which have what they want the system to have in one week. Those are probably the most important or essential functions in customers opinion.

• On-site Customer: The customers are sitting next to the developers, thus the developers can easily ask what the customers really want. As the customers do usually not know what they want at the beginning of the project, but they will know as the project is progressed, their requirements can be changed frequently. If they are near the developers, the developers can easily make conversation with them so it can increase the quality of the system (software). Good communication => High quality software.

• Small Releases: The software is often released rather than the one final software is released at the end of project. Thus, the customers can know what the software will look like and if it fulfills what they want. The developers can also get the feedback from the customers which can help the developers to make the system as what it should be. It can bring about another benefit. As each time releases working version of software, the developers and customers can, somehow, have the software with the certain functionalities when the project is cancelled.

• Simple Design: Design the system as simple as possible but works. It can prevent from over-engineering. This can also deliver business value quickly so the customers can get what they want early. In this case, both customers and developers can have more time and money to reconsider what are more required. The developers can always refactor the existing code and simple design can help them to do so, for "simple design" does NOT mean "bed design". It might mean simple to maintain, simple to understand and simple to redesign.

• Pair Programming: Two programmers share one computer to programme. When they work together, one think tactically about the part of the programme which hs/she is about to code whereas the other one thinks strategically about how that part fits into the whole programme. With pair programming, The one can learn from the other one who is more experienced, and vice versa. This practice can cause better communication and feedback, and those can heighten the quality of the software. As both know about the programme they are working on, it can increase truck factor which means reducing the risk of the project failure.

• Testing - Test First: The tests are created first before starting coding. First with all those tests, the programmers can know what functions they need to make. They can also know whether their programme fulfills the requirements or not. They can code the programme 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.

• Refactoring: Refactoring is changing the existing code to improve its design and readability. It can make simple design possible, and can help the programmers easily change the programme as customers require. It is easy to refactor with tests. After refactoring, if the programme is still passed all the tests, it may mean the changes did not break any existing code. (The recommended book to read for refactoring is "Refactoring, Improving the Design of Existing Code" written by Martin Fowler and published by Addison Wesley. ISBN: 9780201485677, $79.95).

• Collective Ownership: There is no owner of any particular code so anyone can change any code. It can improve productivity and reduce the risk of the truck factor. Tests and coding standard make it possible.

• Coding Standards: Every programmer follows one agreed coding standard, including indentation, capitalisation, names and so on, can improve 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 these understandable.

• Continuous Integration: Team members integrate and test frequently what they made rather than waiting all of them finish the parts assigned and put them all together to test. If they wait until all the members finish coding, they will face many problems to make the programmes work.

• 40 Hour Week: No overtime! Overtime rather decreases than increases the productivity. I'd like to quote the words from Jason Statham, performing in the movie 'Transporter', which is my favourite.
  
  "I can't think straight when I'm tired. After a good night's sleep...I always see things better."

• Metaphor: Using a simple metaphor to describe what the system is like can help to understand the programme and communicate with it. (Metaphor is probably the least popular XP practice)

Am I right???

I'm very excited at learning XP. I hope we all enjoy this subject.

※ References

Avison D. & Fitzgerald G. 2006, Information Systems Development, 4th edn, Mc Graw Hill, Maidenhead.

Wells, D. 2001, Extreme Programming: A gentle introduction. viewed 03 August 2007, <http://www.extremeprogramming.org>

First Post

I've just started using blogger!