Recently, software development teams using agile processes have started widely adopting test-driven development. Despite its name, "test driven" or "test first" development isn't really a testing technique. Also known as test-driven design, TDD works like this: For each small bit of functionality the programmers code, they first write unit tests. Then they write the code that makes those unit tests pass. This forces the programmer to think about many aspects of the feature before coding it. It also provides a safety net of tests that the programmers can run with each update to the code, ensuring that refactored, updated, or new code doesn't break existing functionality. TDD can also extend beyond the unit or "developer facing" test. Many teams, including my own, use "customer facing" or "story" tests to help drive coding. These tests and examples, written in a form understandable to both business and technical teams, illustrate requirements and business rules. Customer-facing tests might include functional, system, end-to-end, performance, security, and usability tests. Programmers write code to make these tests pass, which shows the product owners and stakeholders that the delivered code meets their expectations. The results indicate that, in general, TDD has a small positive effect on quality but little to no discernible effect on productivity. However, subgroup analysis has found both the quality improvement and the productivity drop to be much larger in industrial studies in comparison with academic studies. A larger drop of productivity was found in studies where the difference in test effort between the TDD and the control group's process was significant. A larger improvement in quality was also found in the academic studies when the difference in test effort is substantial; however, no conclusion could be derived regarding the industrial studies due to the lack of data. Finally, the influence of developer experience and task size as moderator variables was investigated, and a statistically significant positive correlation was found between task size and the magnitude of the improvement in quality. Choreographies have been proposed as decentralized and scalable solutions for composing web services. Nevertheless, inherent characteristics of SOA such as dynamicity, scale, and governance issues make the automated testing of choreographies difficult. Nevertheless, inherent characteristics of SOA such as dynamicity, scale, and governance issues make the automated testing of choreographies difficult. The goal of our research is to adapt the automated testing techniques used by the Agile Software Development community to the SOA context. To achieve that, we aim to develop software tools and a methodology to enable Test-Driven Development (TDD) of web service choreographies.

1. H. M. A. Bucchiarone and F. Severoni. Testing service composition. In 8th Argentine Symposiumon Software Engineering (ASSE'07), Argentina, 2007.
2. G. Canfora and M. Di Penta. Testing services and service-centric systems: challengesandopportunities. IT Professional, 8(2):10 –17, march-april 2006.
3. G. Canfora and M. Di Penta. Service- oriented architectures testing: A survey. In A. De Lucia and F. Ferrucci, editors, Software Engineering, volume 5413 of LNCS, pages 78–105. Springer, 2009.
4. L. Frantzen, M. N. Huerta, Z. G. Kiss, and T. Wallet. On-The-Fly Model- Based Testing of Web Services with Jambition. In 5th International Workshop on Web Services and Formal Methods – WS-FM 2008, 2009.
5. P. Mayer and D. L¨ubke. Towards a BPEL unit testing framework. In Proceedings of the 2006 workshop on Testing, analysis, and verification of web services and applications, TAV-WEB '06, pages 33–42, New York, NY, USA, 2006. ACM.
6. A. Stefanescu, S. Wieczorek, and A. Kirshin. MBT4Chor: A model-based testing approach for service choreographies. In Proceedings of the 5th European Conference on Model Driven Architecture – Foundations and Applications, ECMDA-FA '09, Berlin, Heidelberg, 2009.
7. Z. Wang, L. Zhou, Y. Zhao, J. Ping, H. Xiao, G. Pu, and H. Zhu. Web services choreography validation. Service Oriented Computing Applications, 4, December 2010.
8. L. Zhou, J. Ping, H. Xiao, Z. Wang, G. Pu, and Z. Ding. Automatically testing web services choreography with assertions. In Proceedings of the 12th international conference on Formal engineering methods and software engineering, ICFEM'10, pages 138–154. Springer-Verlag, 2010.
9. T. Huedo-Medina, J. Sa´nchez-Meca, F. Mar?´n-Mart?´nez, and J. Botella, "Assessing Heterogeneity in Meta-Analysis: Q statistic or I2 Index?" Psychological Methods, vol. 11, no. 2, pp. 193-206, 2006.
10. G. Melnik and F. Maurer, "A Cross-ProgramInvestigationofStudents' Perceptions of Agile Methods," Proc. 27th Int'l Conf. Software Eng. , pp. 481-488, 2005.
11. S. Kollanus and V. Isomo¨ tto¨nen, Understanding TDD in Academic Environment: Experiences from Two Experiments," Proc. Eighth Int'l Conf. Computing Education Research, pp. 25-31, 2008.
12. A. Rendell, "Effective and Pragmatic Test Driven Development," Proc. AGILE, pp. 298-303, 2008.
13. J. Langr, "Evolution of Test and Code via Test-First Design," Proc. ACM Conf. Object-Oriented Programming, Systems, Languages, and Applications, http:/www . objectmentor. com /resources/arti cles/tfd. pdf, Oct. 2001.
14. D. H. Steinberg, "The Effect of Unit Tests on Entry Points, Coupling and Cohesion in an Introductory Java Programming Course," Proc. XP Universe, Oct. 2001.
15. J. Sanchez, L. Williams, and E. Maximilien, "On the Sustained Use of a Test-Driven Development Practice at IBM," Proc. AGILE, pp. 5-14, 2007.
16. L. Madeyski, "The Impact of Pair Programming and Test-Driven Development on Package Dependencies in Object-Oriented Design—An Experiment," Proc. Seventh Int'l Conf. Product-Focused Software Process Improvement, pp. 278-289, 2006.

Test-driven Development meta-analysis Code Quality Programmer Productivity Agile Software Development.