Fixed code highlighting in tutorial

docs/tutorial.md

@@ -43,6 +43,7 @@ In this spirit, we'll start "from the outside in", and
 write our features before implementing them. A first draft might look
 something like the following:
 
+```cucumber
 Feature: Report Abuse
 
 	As a website user
@@ -55,6 +56,7 @@ something like the following:
 		When I select "Outdated"
 		And I press the button
 		Then I should see "Thanks for your submission"
+```
 
 The "syntax" conventions used here are called the 
 ["Gherkin" language](https://github.com/cucumber/cucumber/wiki/Gherkin).
@@ -76,12 +78,14 @@ so our next move is to review what's already available:
 The step definitions include form interactions, so we only
 need to adjust our steps a bit to make them executable.
 
+```cucumber
 Scenario: Report abuse through preselected options
 	Given I go to a page
 	Then I should see "Report this page"
 	When I select "Outdated" from "Reason"
 	And I press "Submit Report"
 	Then I should see "Thanks for your submission"
+```
 
 This type of refactoring is quite common, since step definitions
 are ideally abstracted and shared between features. In this case,
@@ -97,10 +101,12 @@ Each test run starts with a clean database, meaning there's no pages
 to open in a browser either. Let's fix this by defining one,
 and asking Behat to open it:
 
+```cucumber
 Scenario: Report abuse through preselected options
 	Given a "page" "My Page"
 	Given I go to the "page" "My Page"
 	...
+```
 
 ## SilverStripe Code
 
@@ -193,10 +199,12 @@ and a clean slate on each run.
 
 At the end of our `report-abuse.feature` file, add the following:
 
+```cucumber
 Scenario: Report abuse through preselected options
 	...
 	Then I should see "Thanks for your submission"
 	And there should be an abuse report for "My Page" with reason "Outdated"
+```
 
 Running behat again will produce an undefined step, with a helpful PHP boilerplate
 to get us started: