Research Question: Does gradual typing help developers test their code?

• Alternative RQ: Do different type enforcement strategies reduce the effort needed to unit test a program?
• Definitions
  • Gradual Typing: Combination of static type system, dynamic type enforcement, and untyped programming language (syntax and semantics)
    • Typed Racket type system (very close to TypeScript)
      • Fix types
    • Racket
      • Fix benchmarks
    • Natural vs. Transient vs. Erasure
  • Test: Unit testing
    • All modules and all units (functions, classes, etc.)
      • Except fake modules
    • Integration testing?
    • System-wide testing?
    • Uniform tests because it's otherwise difficult to compare number of tests and size of tests (in terms of which criterion is better)
    • Unit testing should kill all mutants
  • Help: Reduce effort
  • Code: TR/R (Typed Racket / Racket) programs (GTP)
• If statement coverage is used for test minimization, the different mutation score graphs (along the lattice) illustrate whether statement coverage can be used with a specific semantic
• Test minimization options
  • Remove tests until the mutation score drops
  • Remove tests until criterion-based threshold

• Map from Configurations to Mutation Score
  • Adding to Struct in mutant-factory-data.rkt
• How to Remove Tests
• How to Add Types
  • Separate File?
  • Configurable for program instrumentation
    • program-instrumentation/instrument-modules-and-insert-interface-adapter-module.rkt
  • Mutant Factory
• When to Enqueue Additional Tests
  • Mutant Factory

• Add Additional Parameters to Blame Following Function
  • Configurable for blame following
  • blame-following-common.rkt
• Note: Abstract Info Produced by Mutants (List/Struct of Arguments?)

• Mutation Testing
  • Computationally expensive
  • Potentially use population subset
• Statement Coverage
  • Makes mutation testing redundant
  • Makes semantics indistinguishable
  • Need strategy for removing tests

• Preferred Strategies
  • Greedy
    • Calculate test minimization for every possible next step
    • Choose smallest test suite
    • Computationally expensive
  • Combination
    • Use alternate strategy to pick top two/three
    • Use greedy algorithm to pick best
• Alternate Strategies
  • Performance (Profiling)
  • Random
  • Complexity (Size of Modules/Tests)
    • Smaller Modules for Ease
    • Bigger Modules for Coverage
    • Methods (Counting)
      • Lines
      • Symbolic Expressions
      • Top-Level Definitions
      • References to Other Modules
      • External References

• Migratory Typing: Ten Years Later
• An Analysis and Survey of the Development of Mutation Testing
• How to Evaluate Blame for Gradual Types
• Typed-Untyped Interactions: A Comparative Analysis
• Syntax, Semantics, Implementation—and Pragmatics
• [How to Evaluate Blame for Gradual Types, Part 2

• An Evaluation of Test Suite Minimization Techniques
  • Adequate vs. Inadequate
  • Greedy
  • HGS
• Regression testing minimization, selection and prioritization: a survey
  • GE
  • GRE
• An Empirical Study of JUnit Test-Suite Reduction
  • Greedy
  • HGS
  • GRE
  • ILP
• How Profilers Can Help Navigate Type Migration

• Procedures for Reducing the Size of Coverage-based Test Sets
  • The ping-pong procedure is described, and MAR is compared with SAR.
• An Empirical Study of Greedy Test Suite Minimization Techniques Using Mutation Coverage
  • In the methodology section (3B), the mutation matrix and its uses are described.
• Reduction of Test Suites Using Mutation
  • Section 3.1 describes the killing matrix.
• Balancing Trade-Offs in Test-Suite Reduction
  • Section 2.2 describes the Statement Adequate Reduction (SAR) technique. It also mentions how the Greedy algorithm is the most widely used, and it lists the other commonly used algorithms:
    • GE
    • GRE
    • HGS
    • ILP
  • Section 4.1 describes the use of a kill[ing] matrix to compute test minimization algorithms.