|Keywords:||Test-driven development; software testing; unit testing; software design; Engineering and Technology; Teknik och teknologier; Computer Engineering; Datateknik|
|Full text PDF:||http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-113349|
This master’s thesis, carried out at MAN Truck & Bus AG, presents a self-observational case study of the software development methodology Test-driven development (TDD) in the context of developing a framework for human-machine interface concepts in commercial vehicles. Software developers are constantly looking for ways to improve productivity and the quality of their code. TDD has been said to do precisely this, but not many experience reports from new practitioners can be found, making it difficult to know what to expect when using it for the first time. This thesis focuses on the experiences of a beginner to the TDD practice and follows the development of the framework and the changes made to the design over time. The framework, consisting of a C++ server application and an Android client, was developed using TDD. Decisions, obstacles and general experiences from the development process are documented in this report with the aim of finding out how TDD works in practice for a beginner and how well the practice is suited for this particular kind of project. It was concluded that TDD seems to have both benefits and drawbacks, as it appears to facilitate lower coupling of the code and a more structured design, but also complicates the changing of public interfaces since the changes often also affect the test code. Subjectively perceived effects of the practice included that developer focus improved, that testing actually occurred and that the continuous passing of tests gave confidence and a sense of accomplishment to the developer. Furthermore it was concluded that experienced developers may reap more benefits from TDD whereas developers with little experience might have a harder time adjusting to the practice and may not see any notable improvement on the design. The observed developer in this study also found that TDD was difficult to get used to and that it would have been helpful to initially pair up with an experienced TDD practitioner to be properly guided through the first steps and to form good habits. Some parts of the framework developed were left out of the TDD because of complexity and time reasons, leading the suitability of the practice for similar frameworks to be judged as moderate. The areas that induced problematic situations were multithreading, networking and graphical user interfaces which were all considered difficult to handle with TDD.