270 likes | 435 Views
Covrig : A Framework for the Analysis of Code, Test, and Coverage Evolution in Real Software. Paul Marinescu , Petr Hosek , Cristian Cadar Imperial College London. Goal. A nswer questions about software evolution Code quality Test quality Development model
E N D
Covrig: A Framework for the Analysis of Code, Test, and Coverage Evolution in Real Software Paul Marinescu, PetrHosek, CristianCadar Imperial College London
Goal • Answer questions about software evolution • Code quality • Test quality • Development model • Testing improvement opportunities …using software development historical data
Target Audience • Researchers • Hypothesis validation (e.g. are software patches poorly tested?) • Programmers/Project Managers • Assess development quality
Software Metrics • Static • Measured by parsing the software artifacts • Dynamic • Require running the evolving software • More challenging • Very few studies
Example questions • Do executable and test code evolve in sync? • How many patches touch only code/test/none/both? • What is the distribution of patch sizes? • How spread out is each patch through the code? • Is test suite execution deterministic? • How does the overall coverage evolve? • What is the distribution of patch coverage across revisions? • What is the latent patch coverage? • Are bug fixes better covered than other patches? • Is the coverage of buggy code less than average?
Data mining infrastructure Empirical case study
Covrig Overview 2 1 3
Docker Containers • Lightweight, OS-level virtualization • Guest shares kernel with host • Namespace isolation • PID • Network • IPC • Filesystem • Resource limiting • cgroups + Linux Containers + Docker
Docker Containers Features • Isolation • Consistency • Reproducibility • Easy cloud deployment • Performance
Challenges Evolving dependencies • Evolving containers • Custom compile flags (-Wno-error)
Challenges Branching development structure • Consider only the ‘main’ branch Alice Bob r1 r1 r2 r3 r3 r4 r2+r4 m1
Challenges Revisions that fail to compile • Accumulate until reaching a compilable revision r1 r2 r3 r1+r2+r3
Data mining infrastructure Empirical case study
Case Study Subjects 1500 revisions and 12 years of development in total
Is test suite execution deterministic? FAIL/PASS determinism
Is test suite execution deterministic? Coverage determinism
Test Suite Nondeterminism Causes • Bugs • Race conditions • Hardcoded wall clock timeouts • Incorrect resource consumption expectations • Random test data • Benign race conditions
Are patches properly tested? Sometimes
Patch coverage 0% 0% 0% 0% 0% 0%
Does covered code contain fewer bugs that not covered code? Not really
Does covered code contain fewer bugs that not covered code? 85 total bugs
Conclusions Dynamic software metrics mining Case study on 6 systems/1500 revisions/12 years of development Open source extensible infrastructure http://srg.doc.ic.ac.uk/projects/covrig/