Difference between revisions of "Guidance Cards - Test"

From School of CS Student Wiki
Jump to navigation Jump to search
gravatar Mbax9mb5 [userPHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs)
m
gravatar Mbax9mb5 [userPHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs)
m
Line 5: Line 5:
 
<div style="font-size: 140%;"><span style="background:#ff0">'''Requires Review/Re-wording'''</span></div>
 
<div style="font-size: 140%;"><span style="background:#ff0">'''Requires Review/Re-wording'''</span></div>
 
<div class="mw-collapsible-content">
 
<div class="mw-collapsible-content">
<big>''"When you have a choice of 'simplest' test case, it doesn't matter which you choose, provided you complete all tests in a one group before attempting the next group"''</big><br />
+
<big>''When you have a choice of next simplest test, it doesn't matter which you choose as long as you complete all the tests in one feature group before starting on the next.''</big><br />
 
[[File:Test 1.jpg|200px]]<br />
 
[[File:Test 1.jpg|200px]]<br />
  
Line 49: Line 49:
 
==Test Card 3==
 
==Test Card 3==
 
<div style="font-size: 140%;"><span style="background:#ff0">'''Requires Review/Re-wording'''</span></div>
 
<div style="font-size: 140%;"><span style="background:#ff0">'''Requires Review/Re-wording'''</span></div>
<div class="mw-collapsible-content"><big>''"Choose the simplest 'Happy Path' case for your first test"''</big> <br />
+
<div class="mw-collapsible-content"><big>''For the next test case, write the simplest test you can think of that will fail against the current production code.''</big> <br />
 
[[File:Test 3.jpg|200px]]<br />
 
[[File:Test 3.jpg|200px]]<br />
 
----
 
----
Line 61: Line 61:
 
<div style="font-size: 140%;"><span style="background:#ff0">'''Requires Review/Re-wording'''</span></div>
 
<div style="font-size: 140%;"><span style="background:#ff0">'''Requires Review/Re-wording'''</span></div>
 
<div class="mw-collapsible-content">
 
<div class="mw-collapsible-content">
 +
<big>''Write test cases at the boundaries of the different types of behaviour that you need to support.''</big> <br />
 
[[File:Test 4.jpg|200px]]<br />
 
[[File:Test 4.jpg|200px]]<br />
 
</div></div>
 
</div></div>
Line 69: Line 70:
 
<div style="font-size: 140%;"><span style="background:#ff0">'''Requires Review/Re-wording'''</span></div>
 
<div style="font-size: 140%;"><span style="background:#ff0">'''Requires Review/Re-wording'''</span></div>
 
<div class="mw-collapsible-content">
 
<div class="mw-collapsible-content">
 +
<big>''Write test cases for sad path cases, too.''</big> <br />
 
[[File:Test 5.jpg|200px]]<br />
 
[[File:Test 5.jpg|200px]]<br />
 
</div></div>
 
</div></div>

Revision as of 16:09, 25 July 2014

Part of Red-Green-Go! See FizzBuzz Example

Test Card 1

Requires Review/Re-wording

When you have a choice of next simplest test, it doesn't matter which you choose as long as you complete all the tests in one feature group before starting on the next.
Test 1.jpg

Carefully written TDD Test Suites provide confidence in the code supporting the system functionality and also help us understand the subtleties of more complex problems. Kent Beck describe this as "Managing Fear" ( fear in the sense of this-is-a-hard-problem-and-I-can’t-see-the-end-from-the-beginning ).

In order to get most of TDD we aim to write as many tests as possible to describe a certain piece of functionality thus uncovering more details about it and reducing conceptual complexity.

A good example of the application of this is the FizzBuzz application. By writing multiple tests for both the "Fizz" and "Buzz" cases we discover a simplistic and elegant solution for the "FizzBuzz" case (instead of handling "FizzBuzz" as a separate functional piece it is being treated as a combination of "Fizz" and "Buzz" cases).

If we consider an alternative test case arrangement - first tackling the "FizzBuzz" case and later the individual "Fizz" and "Buzz" Cases, it would have been much harder to outline the solution.


http://goo.gl/dShqZP | QR Code

Test Card 2

Requires Review/Re-wording
"Choose the simplest 'Happy Path' case for your first test"

Test 2.jpg


Why choosing the happy path is sensible place to start + simple example <br/ Happy paths tend to be the shortest path - straight down the middle of the functional graph. The simplest smallest vertical slice of functionality

The first agile principle: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."


One of the best ways to maximise business value early in the development is to focus on delivering all the major functionality. This approach is called "happy path" scenario.


Also known as the "sunny day" scenario, the happy path is the "normal" path of execution through a use case or through the software that implements it. Nothing goes wrong, nothing out of the normal happens, and we swiftly and directly achieve the user's or caller's goal.


http://goo.gl/h61rDs | QR Code

Test Card 3

Requires Review/Re-wording
For the next test case, write the simplest test you can think of that will fail against the current production code.

Test 3.jpg


http://goo.gl/h61rDs | QR Code

Test Card 4

Requires Review/Re-wording

Write test cases at the boundaries of the different types of behaviour that you need to support.
Test 4.jpg


Test Card 5

Requires Review/Re-wording

Write test cases for sad path cases, too.
Test 5.jpg

Authors

  • gravatar Mbasssme [userPHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] ·
  • gravatar Mbax9mb5 [userPHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+]