Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Brett Daniel

dblp:04/5890 · DBLP profile ↗
← Back
6ranked-venue papers
5as first author
0since 2021 · last 2011
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 6 · 5 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
5 papers
Software testing · 59% Debugging and program repair · 28% Software maintenance and evolution · 12%

Topics — the 12 heaviest of 13, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Software testing
test repair
0.332011
ReAssert: a tool for repairing broken unit tests · ICSE 2011
On test repair using symbolic execution · ISSTA 2010
ReAssert: Suggesting Repairs for Broken Unit Tests · ASE 2009
Debugging and program repair
automated program repair
0.222011
ReAssert: a tool for repairing broken unit tests · ICSE 2011
On test repair using symbolic execution · ISSTA 2010
Debugging and program repair › automated program repair
test code repair
0.112010
On test repair using symbolic execution · ISSTA 2010
Software testing › test repair
automated test repair
0.112009
ReAssert: Suggesting Repairs for Broken Unit Tests · ASE 2009
Software testing › test generation
automated test generation
0.112008
Predicting Effectiveness of Automatic Testing Tools · ASE 2008
Software testing
automated testing
0.112007
Automated testing of refactoring engines · ESEC/SIGSOFT FSE 2007
Software maintenance and evolution
refactoring
0.112007
Automated testing of refactoring engines · ESEC/SIGSOFT FSE 2007
Software maintenance and evolution › refactoring
refactoring engines
0.112007
Automated testing of refactoring engines · ESEC/SIGSOFT FSE 2007
Software testing › system software testing › language processor testing
refactoring engine testing
0.112007
Automated testing of refactoring engines · ESEC/SIGSOFT FSE 2007
Software testing
unit testing
0.122011
ReAssert: a tool for repairing broken unit tests · ICSE 2011
ReAssert: Suggesting Repairs for Broken Unit Tests · ASE 2009
Empirical software engineering
software metrics
0.012008
Predicting Effectiveness of Automatic Testing Tools · ASE 2008
Software testing
test generation
0.012007
Automated testing of refactoring engines · ESEC/SIGSOFT FSE 2007

Methods — techniques the papers use, named apart from their topics

automated repair · 0.1symbolic execution · 0.1program transformation · 0.1program metrics · 0.1decision tree · 0.1
YearPublicationVenuePosition
2011 ReAssert: a tool for repairing broken unit tests
abstract
Successful software systems continuously change their requirements and thus code. When this happens, some existing tests get broken because they no longer reflect the intended behavior, and thus they need to be updated. Repairing broken tests can be time-consuming and difficult.
Brett Daniel, Danny Dig, Tihomir Gvero, Vilas Jagannath, Johnston Jiaa, Damion Mitchell, Jurand Nogiec, Shin Hwei Tan, Darko Marinov
ICSE1
2010 On test repair using symbolic execution
abstract
When developers change a program, regression tests can fail not only due to faults in the program but also due to out-of-date test code that does not reflect the desired behavior of the program. When this occurs, it is necessary to repair test code such that the tests pass. Repairing tests manually is difficult and time consuming. We recently developed ReAssert, a tool that can automatically repair broken unit tests, but only if they lack complex control flow or operations on expected values.
Brett Daniel, Tihomir Gvero, Darko Marinov
ISSTA1
2009 Reducing the Costs of Bounded-Exhaustive Testing
Vilas Jagannath, Yun Young Lee, Brett Daniel, Darko Marinov
FASE3
2009 ReAssert: Suggesting Repairs for Broken Unit Tests
abstract
Developers often change software in ways that cause tests to fail. When this occurs, developers must determine whether failures are caused by errors in the code under test or in the test code itself. In the latter case, developers must repair failing tests or remove them from the test suite. Repairing tests is time consuming but beneficial, since removing tests reduces a test suite's ability to detect regressions. Fortunately, simple program transformations can repair many failing tests automatically. We present ReAssert, a novel technique and tool that suggests repairs to failing tests' code which cause the tests to pass. Examples include replacing literal values in tests, changing assertion methods, or replacing one assertion with several. If the developer chooses to apply the repairs, ReAssert modifies the code automatically. Our experiments show that ReAssert can repair many common test failures and that its suggested repairs correspond to developers' expectations.
Brett Daniel, Vilas Jagannath, Danny Dig, Darko Marinov
ASE1
2008 Predicting Effectiveness of Automatic Testing Tools
abstract
Automatic white-box test generation is a challenging problem. Many existing tools rely on complex code analyses and heuristics. As a result, structural features of an input program may impact tool effectiveness in ways that tool users and designers may not expect or understand. We develop a technique that uses structural program metrics to predict the test coverage achieved by three automatic test generation tools. We use coverage and structural metrics extracted from 11 software projects to train several decision tree classifiers. Our experiments show that these classifiers can predict high or low coverage with success rates of 82% to 94%.
Brett Daniel, Marat Boshernitsan
ASE1
2007 Automated testing of refactoring engines
abstract
Refactorings are behavior-preserving program transformations that improve the design of a program. Refactoring engines are tools that automate the application of refactorings: first the user chooses a refactoring to apply, then the engine checks if the transformation is safe, and if so, transforms the program. Refactoring engines are a key component of modern IDEs, and programmers rely on them to perform refactorings. A bug in the refactoring engine can have severe consequences as it can erroneously change large bodies of source code.
Brett Daniel, Danny Dig, Kely Garcia, Darko Marinov
ESEC/SIGSOFT FSE1