Update README.md

TDDMicroExercises/README.md

@@ -2,29 +2,38 @@
 
 ## Instructions
 
-Here follow 4 distinct problems. They could be code you inherited from a legacy code-base. Now you want to write unit tests for them, and to do so you will need to do some refactoring. Take care when refactoring not to change interfaces which client code may rely on. Apply the unit testing style and framework you are most comfortable with. You can choose to use stubs or mocks or none at all. If you do, you are free to use the mocking tool that you prefer.
+In this repository you'll find starting code for four distinct problems. They could be code you inherited from a legacy code-base. Now you want to write unit tests for them, and that is harder than it needs to be. All of the code snippets fail to follow one or more of the SOLID principles.
+
+For each exercise, there is only one class you are interested in writing tests for right now. As a first step, try to get some kind of test in place before you change the class at all. Identify why the class is hard to write tests for, and which SOLID principles are not being followed.
+
+When you have some kind of test to lean on, refactor the code and make it testable. Take care when refactoring not to alter the functionality, or change interfaces which other client code may rely on. Add more tests to cover the functionality of the particular class you've been asked to get under test.
+
+Apply the unit testing style and framework you are most comfortable with. You can choose to use stubs or mocks or none at all. If you do, you are free to use the mocking tool that you prefer.
 
 #### 1. **TirePressureMonitoringSystem exercise**:  
-write the unit tests for the Alarm class, refactor the code as much as you need to make the class testable
+Write the unit tests for the Alarm class, refactor the code as much as you need to make the class testable.
 
 The Alarm class is designed to monitor tire pressure and set an alarm if the pressure falls outside of the expected range. The Sensor class provided for the exercise fakes the behaviour of a real tire sensor, providing random but realistic values.
 
+Note that there is a MockAlarm and a StubAlarm class provided in the "tests" folder. The purpose of these is purely to demonstrate how a mock and a stub look, you won't need them to complete the exercise.
+
 #### 2. **UnicodeFileToHtmTextConverter exercise**: 
-write the unit tests for the UnicodeFileToHtmTextConverter class, refactor the code as much as you need to make the class testable.
+Write the unit tests for the UnicodeFileToHtmTextConverter class, refactor the code as much as you need to make the class testable.
 
 The UnicodeFileToHtmTextConverter class is designed to reformat a plain text file for display in a browser.
 
-#### 3. **TelemetrySystem exercise**: 
-write the unit tests for the TelemetryDiagnosticControls class, refactor the code as much as you need to make the class testable.
 
-The responsibility of the TelemetryDiagnosticControls class is to establish a connection to the telemetry server (through the TelemetryClient), send a diagnostic request and successfully receive the response that contains the diagnostic info. The TelemetryClient class provided for the exercise fakes the behavior of the real TelemetryClient class, and can respond with either the diagnostic information or a random sequence. The real TelemetryClient class would connect and communicate with the telemetry server via tcp/ip.
-
-#### 4. **TicketDispenser exercise**: 
-write the unit tests for the TicketDispenser, refactor the code as much as you need to make the class testable
+#### 3. **TicketDispenser exercise**: 
+Write the unit tests for the TicketDispenser, refactor the code as much as you need to make the class testable.
 
 The TicketDispenser class is designed to be used to manage a queuing system in a shop. There may be more than one ticket dispenser but the same ticket should not be issued to two different customers.
 
 
+#### 4. **TelemetrySystem exercise**: 
+Write the unit tests for the TelemetryDiagnosticControls class, refactor the code as much as you need to make the class testable.
+
+The responsibility of the TelemetryDiagnosticControls class is to establish a connection to the telemetry server (through the TelemetryClient), send a diagnostic request and successfully receive the response that contains the diagnostic info. The TelemetryClient class provided for the exercise fakes the behavior of the real TelemetryClient class, and can respond with either the diagnostic information or a random sequence. The real TelemetryClient class would connect and communicate with the telemetry server via tcp/ip.
+
 ## A possible solution
 
 Here you find one of the possible solutions for the exercise: [proposed solution.] (https://github.com/lucaminudel/TDDwithMockObjectsAndDesignPrinciples/tree/master/TDDMicroExercises.ProposedSolution#readme)