mutiny 0.2.0 → 0.2.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 6284685da742cd3e372fb6969484dbef17fcb022
-  data.tar.gz: 4390a6132c28e9c9e6f705307d290ea071f0173a
+  metadata.gz: 73bdf7c448948325e3ed64e73d07c14b1ea2788b
+  data.tar.gz: aad759c85a854b070482db7e9d1775077df23162
 SHA512:
-  metadata.gz: a144740eaa9e502506eb0c7f07e4c95cb633b61e62b41fb932d756341c5ed920564f008f511224868f4614c782169c2effb68889a64944870e054deade9ad33c
-  data.tar.gz: d96ccc36e280c6df7182d7f8d2eb70f88f2dbf436ded930a1d81ec6009c778d8cc4a863a4c366c70ebb78dac2a7ccad70b5173482536209266e6598229e779c9
+  metadata.gz: 634437f983d4893785bafe74e7b269fc41cc922f13dc4caabf79d6ffdc08d1f4e018d250865554ff1d3218e1d177f1039bd2af0bdd23c9869f2b46e1350b3d11
+  data.tar.gz: 29d4deb64ad71594980a15ffc7e97b8214cb18cb18c37541cdef80b984a337e91c2fce0508020f707a8fedf1501a78b2ef019659b1dc15284d18ebc52f5e8bbb

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    mutiny (0.2.0)
+    mutiny (0.2.1)
       gli (~> 2.13.0)
       metamorpher (~> 0.2.2)
       parser (~> 2.2.2)
@@ -50,7 +50,7 @@ GEM
     json (1.8.3)
     memoizable (0.4.2)
       thread_safe (~> 0.3, >= 0.3.1)
-    metamorpher (0.2.2)
+    metamorpher (0.2.3)
       attributable (~> 0.1.0)
       parser (~> 2.2.2)
       unparser (~> 0.2.4)

data/RELEASES.md

@@ -1,5 +1,8 @@
 # Release History
 
+## v0.2.1 (20 August 2015)
+* Fix [#1](https://github.com/mutiny/mutiny/issues/1) - "Uninitialized constant" exception for all commands
+
 ## v0.2.0 (14 August 2015)
 * Implement `mutiny score` mode which performs mutation analysis
 

data/TODO.md

@@ -1,55 +1,12 @@
-### TODO
+## TODO
 
-### New implementation
+### Soon
 
-* Reorganise lib, having in mind a "mutiny-core" which is separate to specific integrations (RSpec, etc), specific mutators (Metamorpher-based, etc), specific reporters (command-line, HTML, etc), etc
+* Documentation for other maintainers
+* Reorganise lib, having in mind a "mutiny-core" which is separate to specific integrations (RSpec, etc), specific mutators (Metamorpher-based, etc), specific reporters (command-line, HTML, etc), etc. Consider hexagonal architecture.
 
-#### Analysis mode
-* Should calculate mutation score
-  * Need to figure out approach for running tests on a mutant
 
-### Original implementation
+### Later
 
-* Experimentation to validate approach
-  * Write scripting
-      * Incremental: Should generate mutant delta (new / deleted mutants) between two git commits. Creating new mutants should be possible from existing change detector. Deleting obsoleted mutants will likely require enhancements to the change detector.
-      * Experimental harness: should run non-incremental mode for each commit, and compare to results of incremental mode. Store data for paper and print a summary that shows the number of mutants evaluated by incremental and non-incremental mode.
-
-  * Candidate projects
-      * Thor: https://github.com/erikhuda/thor
-      * Rake (ruled out as it uses minitest rather than RSpec)
-      * Rack (ruled out as it uses Bacon rather than RSpec)
-      * ActiveSupport and other Rails subgems (ruled out as it uses minitest rather than RSpec)
-
-  * Experiments
-      * Compare incremental and non-incremental mutator (seeding of faults) to determine typical magnitude of change over a project. What kind of granularity do we need to make a significant difference (file < method < ast nodes)?
-      * Compare incremental and non-incremental analyser to determine typical impact of change on mutation testing. Analyser will first need to be enhanced with an incremental model that determines which of a set of existing mutants need to be reevaluated.
-
-  * Overall aim: investigate the time savings of using incremental mode over the course of the project's history
-      * Measurements
-          * Could compare time taken for mutation testing each commit.
-          * Alternatively, could compare the number of mutants that need to be re-evaluated. This would allow experimentation to proceed without actually executing any tests; just creating mutants and marking those which need to be re-evaluated. The incremental mode should count any new mutants, mark any mutants from the previous round that need to be re-evaluated, (and mark any mutants from the previous round that need to be deleted?).
-      * Validity of results:
-          * Whatever is measured, I need to compare the _results_ of incremental and non-incremental modes to ensure that incremental mode is correct.
-          * Might need to enhance the change detector to be able to identify dependencies of units. For example, if `max_spec` tests `max` and `max` uses `calculator`, `max_spec` is dependent on calculator. If `calculator` changes, `max_spec` should be detected as impacted.
-
-* Try new approach to specifying mutation operators, particularly if this makes incremental mutation testing easier.
-    * Add a Rewrite class to Ast module which can build and apply rewritings based on syntax in comments
-    * Add notions of MutationOperator that are specified with single rewrite, and with several rewrites.
-
-* More fine-grained change detection. Some ideas:
-  * When an example is removed from a spec, we should be able to quickly recompute the mutation score. To allow this, we would need to store the results of each example for each mutant. We then remove the results for the deleted example, and recalculate the mutation score without running any tests.
-
-  * When a change to a unit is equivalent to swapping the unit for a previously analysed mutant of that unit, we should be able to quickly recompute the mutation score. We simply swap the mutant and unit in the results, and recalculate whether mutants are alive or dead (the new unit might cause different mutants to die). Again, to allow this we would need to store the results of each example for each mutant.
-
-  * When a change to a unit is localised to a single line / method / subset of the file (i.e., a fragment), we only need to recalculate the mutants for that fragment. (However, I suspect we will often need to re-test the mutants and source file to obtain an accurate mutation score: i.e., unlike the points above, this speed up only impacts mutant creation and not mutant analysis) To allow this, the mutation creation component should be able to locate mutation sites in a specific fragment of a file.
-
-* Housekeeping
-
-  * Consider refactoring mutant.rb so that it does not contain a code attribute (perhaps instead it should compute code by passing the file and line number to its operator?)
-
-  * Should the change detector be a separate component, or should it be part of the core?
-
-  * Tests for Session.
-
-* Extend framework to explore Program Analyser and more sophisticated Test Case Provider components (see OmniGraffle diagram)
+* Profiling to determine bottlenecks
+* [Incrementality](design/incrementality.md)

data/design/incrementality.md

@@ -0,0 +1,32 @@
+## Incrementality
+
+* Experimentation to validate approach
+  * Write scripting
+      * Incremental: Should generate mutant delta (new / deleted mutants) between two git commits. Creating new mutants should be possible from existing change detector. Deleting obsoleted mutants will likely require enhancements to the change detector.
+      * Experimental harness: should run non-incremental mode for each commit, and compare to results of incremental mode. Store data for paper and print a summary that shows the number of mutants evaluated by incremental and non-incremental mode.
+
+  * Candidate projects
+      * Thor: https://github.com/erikhuda/thor
+      * Rake (ruled out as it uses minitest rather than RSpec)
+      * Rack (ruled out as it uses Bacon rather than RSpec)
+      * ActiveSupport and other Rails subgems (ruled out as it uses minitest rather than RSpec)
+
+  * Experiments
+      * Compare incremental and non-incremental mutator (seeding of faults) to determine typical magnitude of change over a project. What kind of granularity do we need to make a significant difference (file < method < ast nodes)?
+      * Compare incremental and non-incremental analyser to determine typical impact of change on mutation testing. Analyser will first need to be enhanced with an incremental model that determines which of a set of existing mutants need to be reevaluated.
+
+  * Overall aim: investigate the time savings of using incremental mode over the course of the project's history
+      * Measurements
+          * Could compare time taken for mutation testing each commit.
+          * Alternatively, could compare the number of mutants that need to be re-evaluated. This would allow experimentation to proceed without actually executing any tests; just creating mutants and marking those which need to be re-evaluated. The incremental mode should count any new mutants, mark any mutants from the previous round that need to be re-evaluated, (and mark any mutants from the previous round that need to be deleted?).
+      * Validity of results:
+          * Whatever is measured, I need to compare the _results_ of incremental and non-incremental modes to ensure that incremental mode is correct.
+          * Might need to enhance the change detector to be able to identify dependencies of units. For example, if `max_spec` tests `max` and `max` uses `calculator`, `max_spec` is dependent on calculator. If `calculator` changes, `max_spec` should be detected as impacted.
+
+
+* More fine-grained change detection. Some ideas:
+  * When an example is removed from a spec, we should be able to quickly recompute the mutation score. To allow this, we would need to store the results of each example for each mutant. We then remove the results for the deleted example, and recalculate the mutation score without running any tests.
+
+  * When a change to a unit is equivalent to swapping the unit for a previously analysed mutant of that unit, we should be able to quickly recompute the mutation score. We simply swap the mutant and unit in the results, and recalculate whether mutants are alive or dead (the new unit might cause different mutants to die). Again, to allow this we would need to store the results of each example for each mutant.
+
+  * When a change to a unit is localised to a single line / method / subset of the file (i.e., a fragment), we only need to recalculate the mutants for that fragment. (However, I suspect we will often need to re-test the mutants and source file to obtain an accurate mutation score: i.e., unlike the points above, this speed up only impacts mutant creation and not mutant analysis) To allow this, the mutation creation component should be able to locate mutation sites in a specific fragment of a file.

data/lib/mutiny/mutants/mutant_set.rb

@@ -1,4 +1,5 @@
 require_relative "mutant"
+require "delegate"
 
 module Mutiny
   module Mutants

data/lib/mutiny/version.rb

@@ -1,3 +1,3 @@
 module Mutiny
-  VERSION = "0.2.0"
+  VERSION = "0.2.1"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: mutiny
 version: !ruby/object:Gem::Version
-  version: 0.2.0
+  version: 0.2.1
 platform: ruby
 authors:
 - Louis Rose
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2015-08-14 00:00:00.000000000 Z
+date: 2015-08-20 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: parser
@@ -172,6 +172,7 @@ files:
 - Rakefile
 - TODO.md
 - bin/mutiny
+- design/incrementality.md
 - examples/buggy_calculator/.rspec
 - examples/buggy_calculator/lib/calculator.rb
 - examples/buggy_calculator/lib/calculator/max.rb