aboutsummaryrefslogtreecommitdiffstats
path: root/bruiser
diff options
context:
space:
mode:
authorbloodstalker <thabogre@gmail.com>2017-04-27 20:36:12 +0000
committerbloodstalker <thabogre@gmail.com>2017-04-27 20:36:12 +0000
commit27e86cc0a3fe5c9cd78360b7fc17fd9f276bb591 (patch)
tree138fc79f4bca35b71684dc87f52fcf02a4d37c66 /bruiser
parentfixes (diff)
downloadmutator-27e86cc0a3fe5c9cd78360b7fc17fd9f276bb591.tar.gz
mutator-27e86cc0a3fe5c9cd78360b7fc17fd9f276bb591.zip
the ideas for bruiser
Diffstat (limited to 'bruiser')
-rw-r--r--bruiser/README.md12
1 files changed, 12 insertions, 0 deletions
diff --git a/bruiser/README.md b/bruiser/README.md
new file mode 100644
index 0000000..07139c6
--- /dev/null
+++ b/bruiser/README.md
@@ -0,0 +1,12 @@
+## bruiser
+
+### What is it?
+The idea is simple. bruiser will try to break your code. One way to do this is have bruiser mutate the source code and then run the code to see if it breaks. The other way to do this is have bruiser first "analyze" the code, to get to know it and then decide how to break it.<br/>
+
+### Why?
+Well you can probably use your imagination to come up with practical uses for bruiser, but I'm doing this because it's fun.<br/>
+
+### Implementation Ideas(Or bruiser Requirements if you will)
+The analysis part can be handled by m0(mutator-lvl0), while bruiser consumes the report generated by m0. I'm leaning towards using the XML reoport mostly because of X-Path.<br/>
+For the "getting to know the code" part we can do a feature extraction/categorization on the reports and then have some sort of a mutation database based on the results of running the mutants.<br/>
+We need to have the makefile for the source code so we can build the mutants, fork them as a separate process(we don't want to crash bruiser), get the results and repeat. For that reason bruiser might be implented as a shell of some sort.<br/>