Evaluation of Quality, Productivity, and Defect by applying Test-Driven Development to perform Unit Tests

2020 ◽  
Author(s):  
Myint Myint Moe ◽  
Khine Khine Oo
Keyword(s):  
Test Driven Development ◽  
Unit Tests

scholarly journals Results from an ethnographically-informed study in the context of test-driven development

2016 ◽  
Author(s):  
Simone Romano ◽  
Davide Davide Fucci ◽  
Giuseppe Scanniello ◽  
Burak Turhan ◽  
Natalia Juristo
Keyword(s):  
Work Experience ◽  
Software Developers ◽  
Test Driven Development ◽  
Is Implementation ◽  
Production Code ◽  
Field Notes ◽  
New Feature ◽  
Iterative Software ◽  
The University ◽  
Unit Tests

Background: Test-driven development (TDD) is an iterative software development technique where unit-tests are defined before production code. Previous studies fail to analyze the values, beliefs, and assumptions that inform and shape TDD. Aim: We designed and conducted a qualitative study to understand the values, beliefs, and assumptions of TDD. In particular, we sought to understand how novice and professional software developers, arranged in pairs (a driver and a pointer), perceive and apply TDD. Method: 14 novice software developers, i.e., graduate students in Computer Science at the University of Basilicata, and six professional software developers with work one to 10 years work experience participated in our ethnographically-informed study. We asked the participants to implement a new feature for an existing software written in Java. We immersed ourselves in the context of the study, and collected data by means of contemporaneous field notes, audio recordings, and other artifacts. Results: A number of insights emerge from our analysis of the collected data, the main ones being: (i) refactoring (one of the phases of TDD) is not performed as often as the process requires and it is considered less important than other phases, (ii) the most important phase is implementation, (iii) unit tests for unimplemented functionalities or behaviors are almost never up-to-date, (iv) participants first build a sort of mental model of the source code to be implemented and only then write test cases on the basis of this model; and (v) apart from minor differences, professional developers and students applied TDD in a similar fashion. Conclusions: Developers write quick-and-dirty production code to pass the tests and ignore refactoring.

Problems of test-driven aspect-oriented development

2009 ◽  
Vol 38 (38) ◽  
pp. 180-186
Author(s):  
Aleksandr Sukhorukov
Keyword(s):  
Single Unit ◽  
Negative Impact ◽  
Object Oriented ◽  
Object Oriented Programming ◽  
Test Design ◽  
Aspect Oriented Programming ◽  
Test Driven Development ◽  
New Development ◽  
Unit Tests

Problems of test-driven aspect-oriented developmentTest-driven development and aspect-oriented programming are relatively new development techniques each having its own benefits. However, using aspect-oriented language like AspectJ in test-driven development leads to new types of problems that do not appear if these two approaches are applied separately. These problems arise mainly because aspect-oriented paradigm breaks encapsulation principle - behaviour of class is not implemented just in class itself like in traditional object-oriented programming but can be heavily affected by many external aspects. Traditional unit tests designed to test a single unit are not sufficient any more because behaviour being tested is distributed through several units at once, so test design becomes more complicated. In order to efficiently use these two techniques together such problems have to be identified and ways to workaround them have to be discovered. This paper focuses on those problems, describing the most notable ones. Problem descriptions are based on experience with AspectJ, but most of them are common to any aspect-oriented language with similar features. Some empirically discovered principles are provided that help softening negative impact of those problems.

scholarly journals Results from an ethnographically-informed study in the context of test-driven development

2016 ◽  
Author(s):  
Simone Romano ◽  
Davide Davide Fucci ◽  
Giuseppe Scanniello ◽  
Burak Turhan ◽  
Natalia Juristo
Keyword(s):  
Work Experience ◽  
Software Developers ◽  
Test Driven Development ◽  
Is Implementation ◽  
Production Code ◽  
Field Notes ◽  
New Feature ◽  
Iterative Software ◽  
The University ◽  
Unit Tests

Background: Test-driven development (TDD) is an iterative software development technique where unit-tests are defined before production code. Previous studies fail to analyze the values, beliefs, and assumptions that inform and shape TDD. Aim: We designed and conducted a qualitative study to understand the values, beliefs, and assumptions of TDD. In particular, we sought to understand how novice and professional software developers, arranged in pairs (a driver and a pointer), perceive and apply TDD. Method: 14 novice software developers, i.e., graduate students in Computer Science at the University of Basilicata, and six professional software developers with work one to 10 years work experience participated in our ethnographically-informed study. We asked the participants to implement a new feature for an existing software written in Java. We immersed ourselves in the context of the study, and collected data by means of contemporaneous field notes, audio recordings, and other artifacts. Results: A number of insights emerge from our analysis of the collected data, the main ones being: (i) refactoring (one of the phases of TDD) is not performed as often as the process requires and it is considered less important than other phases, (ii) the most important phase is implementation, (iii) unit tests for unimplemented functionalities or behaviors are almost never up-to-date, (iv) participants first build a sort of mental model of the source code to be implemented and only then write test cases on the basis of this model; and (v) apart from minor differences, professional developers and students applied TDD in a similar fashion. Conclusions: Developers write quick-and-dirty production code to pass the tests and ignore refactoring.

Sign in / Sign up

Export Citation Format

Share Document