diff --git a/artifact_documentation/README.md b/artifact_documentation/README.md
index e5dd52f..8bbeba8 100644
--- a/artifact_documentation/README.md
+++ b/artifact_documentation/README.md
@@ -32,7 +32,7 @@ Once the virtual machine is imported, it will appear in your VirtualBox Manager
You can now start the virtual machine by clicking the green **"Start"** arrow at the top of the VirtualBox Manager (see screenshot below).
-
+
### Resizing the virtual machine screen
@@ -40,7 +40,7 @@ If the virtual machine loads and you find it is not an appropriate size, you can
1. In your VirtualBox VM menu, go to **View > Virtual Screen 1 > ...**. You will see different scaling options; select the one that best suites your screen.
-
+
2. Your menu may look different if you are running a different operating system. However, if given percentages to re-scale they will have the same effect.
@@ -52,7 +52,7 @@ If you leave the virtual machine and return to a black screen or screen saver, p
Once the virtual machine loads, Eclipse will open. In Eclipse, there will be 8 projects loaded on the left side in the Project Explorer. Seven of the projects are from the [Defects4J](https://github.com/rjust/defects4j) defect benchmark; these projects are labeled *Defect_0_Training*, *Defect_1*, *Defect_2*, *Defect_3*, *Defect_4*, *Defect_5*, and *Defect_6*. The eighth project is *Holmes*.
-
+
At the bottom of the window, the Tasks View is open with a list of TODOs. Each TODO maps to a failing test in its respective project that exposes a defect in that project's source code.
For example **TODO: Test 00 (Training)** maps to a failing test in the project *Defect_0_Training* that exposes a defect.
@@ -65,19 +65,19 @@ The runtime for Holmes varies depending on a number of factors, such as input va
1. Double-click the TODO labeled **TODO: Test 00 (Training)**. Within a few seconds, the file *BooleanUtilsTest.java* opens at the ```test_toBoolean_String()``` method. Inside the ```test_toBoolean_String()``` method is the failing test ```assertEquals(false, BooleanUtils.toBoolean("tru");```.
-
+
2. Double-click the method call ```toBoolean``` so that it is highlighted, as show in the screenshot below.
-
+
3. Right-click the highlighted method and click **"Run Holmes"** in the pop-up menu (shown below). The editor will automatically go to the top of the file and some dialog windows may pop up as Holmes generates and executes tests. This process will take a minute or two; to reduce the chances of Holmes or the virtual machine hanging, we selected a defect for which Holmes is quickly able to find similar passing tests.
-
+
Eventually, a view labeled "Holmes View" will open at the bottom of the screen with the results of the execution (as shown below).
-
+
Now let's see how we can use Causal Testing to debug.
@@ -99,11 +99,11 @@ assertEquals(expected, actual);
2. For this test, the method call being tested is ```escapeJava(input)```. Therefore, to invoke Holmes we want to double-click to highlight ```escapeJava```, as shown below.
-
+
3. Right click the highlighted method and select **Run Holmes** from the pop-up menu. The output will appear at the bottom of the screen in the "Holmes View"
-
+
Now that we have the Causal Testing results, we can begin to debug the defect.
@@ -114,11 +114,11 @@ First, we can see that Holmes has provided three similar passing tests and three
Second, we can see that each generated test has a button under it labeled "See Execution Trace". Clicking this button opens a minimized trace of the execution; clicking the button again hides the trace.
-
+
Let's look at the trace for the most similar passing input, ```"String with a slash in it"```:
-
+
We can see that as expected, the final method call to ```escapeJavaStyleString``` returns the same string that was input, as the test expected (```assertEquals(expected,actual)```). When we look at the trace for the original failing test, we can see that this same method call adds an additional character to the input string (```String with a slash (\/) in it```), causing the test to fail.
@@ -130,7 +130,7 @@ To navigate to this final method call ```escapeJavaStyleString``` in Eclipse, do
1. Press and hold the *control* button on your keyboard and hover over the ```escapeJava``` method call in the test method. The method should become a link and open a pop-up menu, as shown in the screenshot below.
-
+
2. Click "Open Declaration" in the pop-up menu. This will take you to the ```escapeJava``` method implementation in the ```StringEscapeutils``` class.
@@ -150,7 +150,7 @@ Given this code exists, we can assume that just erasing this case may fix this d
Let's try adding a flag to the ```escapeJavaStyleString``` method that we can use to control the statements in the case for the ```/``` character. We can do that by first adding a boolean parameter (let's call it ```escapeJava```) to the ```escapeJavaStyleString``` as shown below.
-
+
We can then add a condition for the additional escape character, like so:
@@ -163,12 +163,12 @@ case '/':
After making this addition, there are a number of compiler errors that come up from statements that use the methods we changed. The other ```escapeJavaStyleString``` method needs the same parameter (as shown below).
-
+
We can now go to the calls to ```escapeJavaStyleString``` to add the new parameter values. We know where to go by the red markers in the
right-hand gutter (see screenshot below). You can click each red marker to go to each method call.
-
+
Two of these method calls happen within ```escapeJava``` methods; for these, we want to add ```false``` to the end of the parameter list like so:
@@ -180,13 +180,13 @@ The other two methods that use ```escapeJavaStyleString``` are within ```escapeJ
Once we've addressed all the compiler errors in the ```StringEscapeUtils``` class, we are ready to test our fix. To do so, return to the test class ```StringEscapeutilsTest``` and click the green run button in the top menu bar (circled below). This will run the test suite to see if our test now passes.
-
+
A dialog will pop up asking you to "Select a way to run 'StringEscapeUtilsTest.java'". Select "JUnit Test" and click "Ok".
**Success!** We can see in the JUnit view (shown below) that all tests passed, which means we have fixed the defect.
-
+
Repeat this process with *Defects 2-6* to see how Causal Testing can help with debugging other defects.