Presentation on Test Driven Development

visit http://www.slideshare.net/poonambhasin33/test-driven-development-999356 for presentation on TDD

At last finally the d-day came where all of us had to give a practical shape to our learnings in the software methodologies workshop. Not only the theories class broke all our beliefs of believing and having faith in the “waterfall methodology” but also gave very useful  and informative insights on  why should  we practice other methodologies and how they gain an edge over the traditional “waterfall methodology”

It was through the class we understood that writing good code is not the only criteria in making successful software, but it is the Methodology that stands most crucial in developing a successful software, a good code is of course important but is secondary to the methodology adopted.

 One of the reasons why waterfall model is not adopted much is that it has been adopted from engineering concepts. Though the waterfall model proved extremely successful in the engineering discipline but in the software world it failed badly as the scenario to construct a building is extremely different from constructing software.

In the waterfall model there are four phases i.e. the Requirements Gathering  phase, designing phase , development, testing  and implementation and then finally the deployment phase,  here every phase is freezed before moving on to the next phase. The model works very well if we have to construct a  building or  a bridge where each previous phase is freezed before moving on to the next phase, and it is very important also as in  engineering you can’t move ahead without  completely finalizing  the previous phase .It is  important to first understand the requirements  get  them finalized then  create the blueprint  and get it  finalized,  then moving to the  construction phase and then finally testing  and delivery. But  unfortunately this does not go well with the software engineering process , the reason being  software’s are constructed to help businesses perform better , as businesses  are agile the requirements to create the software  are also agile, they change very   frequently with the changing business environment,  so it is important to adopt the methodology that is agile  and helps  the developers to develop software’s that can be  agile with  the changing requirements of business,   where change management  is not a daunting as in the waterfall model

 It was during the workshop we got a practical exposure to the concept of agile, though being into the software domain we have read a lot about agile but had never received a practical exposure to it. Thanks to our mentor Mr  Parag Shah  for the workshop that we got a practical feel to what is extreme programming all about

Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

Though the definition sounds very simple but is extremely powerful and this is what we actually learnt in the workshop.

 We  started the workshop with a small planning meeting, where I acted as  the customer dictating  down what is to be built  through small stories in order to understand the features and functionalities that have to be included in the software, we also drew  the  various diagrams like the   business process  flow, work flow diagram , Use  case diagram, Class Diagrams, Data base design to actually understand what is required in depth .

We also configured CVS into our systems so as to work in a actual extreme programming environment. One of the laptops of one of our team members acted as the CVS server i.e. the repository for the code and all others acted as clients. Team members working on the client side i.e. the ones writing code checked in the code on to the CVS repository once they were done with the testing of the code on the client side, after checking in the code to the repository we had to run the tests again through HUDSON to make sure that integration is done properly on the server. This is perhaps one of the most interesting feature of Extreme programming called Continuous integration where XP teams integrate and build the software system multiple times per day , this enables very rapid progress. Perhaps surprisingly, integrating more frequently tends to eliminate integration problems

Another important feature that we experienced was pair programming where all the code and tests   for that code is done in pairs, This practice ensures that all production code is reviewed by at least one other programmer, and results in better design, better testing, and better code. So after acting as a customer in the planning meeting I shifted my role to a tester where I developed unit tests for the code to be written………..

 Writing tests first and then code later.. isn’t that strange?????,…… yes  that’s  one of the best features of extreme programming, here coders write tests cases first before moving onto the  coding part, which we call as Test Driven Development. Here all the unit tests are all collected together, and every time any programmer releases any code to the repository every single tests must run correctly. One hundred percent, all the time! This means that programmers get immediate feedback on how they're doing. Additionally, these tests provide invaluable support as the software design is improved.

Another feature that I found most interesting in the workshop was that while doing extreme programming there is always a metaphor that guides the team throughout the building of the software. A metaphor acts like a vision to the entire team and when the team is building a code it makes sure that the code is aligned with the vision .

 I all we covered two iterations in the workshop and  almost developed  and tested what had to be completed in the project

It was an enjoyable experience and we loved learning this powerful practice in a practical way

Presentation on" Test Driven Development"

 http://www.slideshare.net/poonambhasin33/test-driven-development-999356