2019
DOI: 10.1109/tse.2017.2776152
|View full text |Cite
|
Sign up to set email alerts
|

Developer Testing in the IDE: Patterns, Beliefs, and Behavior

Abstract: Software testing is one of the key activities to achieve software quality in practice. Despite its importance, however, we have a remarkable lack of knowledge on how developers test in real-world projects. In this paper, we report on a large-scale field study with 2,443 software engineers whose development activities we closely monitored over 2.5 years in four integrated development environments (IDEs). Our findings, which largely generalized across the studied IDEs and programming languages Java and C#, quest… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
3
1
1

Citation Types

2
35
0

Year Published

2019
2019
2024
2024

Publication Types

Select...
6
2
1

Relationship

3
6

Authors

Journals

citations
Cited by 78 publications
(39 citation statements)
references
References 82 publications
2
35
0
Order By: Relevance
“…Nevertheless, recent studies found that developers perceive and treat production code as more important than test code, thus generating quality problems in the tests [9], [10], [57], [82]. This finding is in line with the experience reported by van Deursen et al [74], who described how the quality of test code was "not as high as the production code [because] test code was not refactored as mercilessly as our production code" [74].…”
Section: Introductionsupporting
confidence: 81%
“…Nevertheless, recent studies found that developers perceive and treat production code as more important than test code, thus generating quality problems in the tests [9], [10], [57], [82]. This finding is in line with the experience reported by van Deursen et al [74], who described how the quality of test code was "not as high as the production code [because] test code was not refactored as mercilessly as our production code" [74].…”
Section: Introductionsupporting
confidence: 81%
“…After that, we use the include and exclude tag of the maven-test-plugin (or of the test task, in the case of GRADLE), so that we consider only the test cases that are actually ran when the project is built. In other words, we consider all test cases that developers of the subject systems ran when they test them, discarding those that are likely to be not reliable from the developers' perspective [60]. Once completed this filtering phase, we use 4 https://cloud.google.com/bigquery/ a pattern matching approach based on naming conventions to find the production class related to a certain test class, as done in many other previous work [34], [61], [62].…”
Section: Linking Production To Test Classesmentioning
confidence: 99%
“…When extracting test classes from the subject systems we only considered those tests available under the include tag of the MAVEN pom file. We adopted this procedure to exclude tests that are not ran when the test or package MAVEN commands are executed [60].…”
Section: Threats To Validitymentioning
confidence: 99%
“…This test suite is large, and has been written on top of a lot of human intelligence and domain knowledge [70]. Developers spend a lot of time in writing the tests [7], so that those tests exercise interesting cases (including corner cases), and so that a good oracle verifies as much as possible the program behavior.…”
Section: Introductionmentioning
confidence: 99%