Browse Source

README-en.md edited on August 1, 2016

Jose R Ortiz Ubarri 8 years ago
parent
commit
69b4be5ce3
1 changed files with 32 additions and 31 deletions
  1. 32
    31
      README-en.md

+ 32
- 31
README-en.md View File

@@ -1,23 +1,23 @@
1
-#Testing and Unit Testing
1
+# Testing and Unit Testing
2 2
 
3 3
 ![](http://demo05.cloudimage.io/s/resize/215/i.imgur.com/D0laI5r.png)
4 4
 ![](http://demo05.cloudimage.io/s/resize/215/i.imgur.com/ggDZ3TQ.png)
5 5
 ![](http://demo05.cloudimage.io/s/resize/215/i.imgur.com/V6xFo00.png)
6 6
 
7
-[Verano 2016 - Ive]
7
+[Verano 2016 - Ive - Coralys]
8 8
 
9
-As you have learned in previous labs, getting a program to compile is only a minor part of programming. The compiler will tell you if there are syntactical errors, but it isn't capable of detecting logical problems in your program. It's very important to test the program's functions to validate that they produce correct results.
9
+As you have learned in previous labs, getting a program to compile is only a minor part of programming. The compiler will tell you if there are any syntactical errors, but it isn't capable of detecting logical problems in your program. It's very important to test the program's functions to validate that they produce correct results.
10 10
 
11 11
 These tests can be performed by hand, this is, running the program multiple times, providing representative inputs and visually checking that the program outputs correct results. A more convenient way is to implement functions in the program whose sole purpose is to validate that other functions are working correctly. In this lab you will be practicing both testing methods.
12 12
 
13 13
 
14
-##Objectives:
14
+## Objectives:
15 15
 
16 16
 1. Design tests to validate several programs “by-hand”, then use these tests to determine if the program works as expected. 
17 17
 2. Create unit tests to validate functions, using the `assert` function.
18 18
 
19 19
 
20
-##Pre-Lab:
20
+## Pre-Lab:
21 21
 
22 22
 Before you get to the laboratory you should have:
23 23
 
@@ -39,7 +39,7 @@ When we test a function's validity we should test cases that activate the variou
39 39
 
40 40
 ---
41 41
 
42
-**Example 1:** if you were to validate the function `isEven(unsigned int n)` that determines if a positive integer *n* is even, you should test the function using even and odd numbers. A set of tests for that function could be:
42
+**Example 1:** If you were to validate the function `isEven(unsigned int n)` that determines if a positive integer *n* is even, you should test the function using even and odd numbers. A set of tests for that function could be:
43 43
 
44 44
 
45 45
 |     Test     | Expected Result |
@@ -49,7 +49,7 @@ When we test a function's validity we should test cases that activate the variou
49 49
 
50 50
 ---
51 51
 
52
-**Example 2:** Suppose that a friend has created a function `unsigned int ageRange(unsigned int age)` that is supposed to return 0 if the age is between 0 and 5 (inclusive), 1 if the age is between 6 and 18 inclusive, and 2 if the age is above 18. A common source of errors in functions like this one are the values near to the limits of each range, for example, the number 5 can cause errors if the programmer did not use a correct comparison. One good set of tests for the `ageRange` function would be:
52
+**Example 2:** Suppose that a friend has created a function `unsigned int ageRange(unsigned int age)` that is supposed to return 0 if the age is between 0 and 5 (inclusive), 1 if the age is between 6 and 18 (inclusive), and 2 if the age is above 18. A common source of errors in functions like this one are the values near to the limits of each range, for example, the number 5 can cause errors if the programmer did not use a correct comparison. One good set of tests for the `ageRange` function would be:
53 53
 
54 54
 |      Test      | Expected Result |
55 55
 |----------------|-----------------|
@@ -63,9 +63,9 @@ When we test a function's validity we should test cases that activate the variou
63 63
 
64 64
 ---
65 65
 
66
-###`Assert` Function:
66
+### The`assert` function:
67 67
 
68
-The `assert(bool expression)` function can be used as a rudimentary tool to validate functions. `assert` has a very powerful yet simple functionality. If the expression that we place between the `assert` parenthesis is *true*, the function allows the program to continue onto the next instruction. Otherwise, if the expression we place between the parenthesis is *false*, the `assert` function causes the program to terminate and prints an error message on the terminal that informs the user about the `assert` instruction that failed.
68
+The `assert(bool expression)` function can be used as a rudimentary tool to validate functions. `assert` has a very powerful, yet simple functionality. If the expression that we place between the `assert` parenthesis is *true*, the function allows the program to continue onto the next instruction. Otherwise, if the expression we place between the parenthesis is *false*, the `assert` function causes the program to terminate and prints an error message on the terminal, that informs the user about the `assert` instruction that failed.
69 69
 
70 70
 For example, the following program will run from start to finish without problems since every expression included in the assert's parentheses evaluates to *true*.
71 71
 
@@ -92,7 +92,7 @@ int main() {
92 92
 
93 93
 ---
94 94
 
95
-The following program will not run to completion because the second `assert` (`assert(j == i);`) contains an expression (`j==i`) that evaluates to *false*.
95
+The following program will not run to completion because the second `assert` (`assert(j == i);`) contains an expression (`j == i`) that evaluates to *false*.
96 96
 
97 97
 ---
98 98
 
@@ -118,16 +118,16 @@ int main() {
118 118
 
119 119
 ---
120 120
 
121
-When the program is run, instead of getting the phrase `”That's all, folks!”` in the terminal, we will obtain something like:
121
+When the program is ran, instead of getting the phrase `"That's all, folks!"` in the terminal, we will obtain something like:
122 122
 
123 123
 `Assertion failed: (j == i), function main, file ../program01/main.cpp, line 8.`
124 124
 
125 125
 The program will not execute the remaining instructions after line 8.
126 126
 
127
-####How to use assert to validate functions?
128 127
 
128
+#### How to use assert to validate functions?
129 129
 
130
-Suppose that  you want to automate the validation of the `ageRange`. One way to do it is by  implementing and calling a function that calls the `ageRange` function with different arguments and verifies that each returned value is equal to  the expected result. If the `ageRange` function returns a value that is not expected, the testing function aborts the program and reports the test that failed. The following illustrates a function to test the `ageRange` function. Observe that it consists of one assert per each of the tests we had listed earlier. 
130
+Suppose that you want to automate the validation of the `ageRange`. One way to do it is by implementing and calling a function that calls the `ageRange` function with different arguments and verifies that each returned value is equal to the expected result. If the `ageRange` function returns a value that is not expected, the testing function aborts the program and reports the test that failed. The following illustrates a function to test the `ageRange` function. Observe that it consists of one assert per each of the tests we had listed earlier. 
131 131
 
132 132
 
133 133
 ---
@@ -164,15 +164,15 @@ void test_ageRange() {
164 164
 ---
165 165
 
166 166
 
167
-##Laboratory Session:
167
+## Laboratory Session:
168 168
 
169
-###Exercise 1: Designing tests by hand:
169
+### Exercise 1: Designing tests by hand
170 170
 
171
-In this exercise you will practice how to design tests to validate functions, using only the function's description and the graphical user interface that is used interact with the function.
171
+In this exercise you will practice how to design tests to validate functions, using only the function's description and the graphical user interface that is used to interact with the function.
172 172
 
173 173
 The exercise **DOES NOT require programming**, it only requires that you understand the function’s description, and your ability to design tests. This exercise and Exercise 2 are an adaptation of the activity described in [1].
174 174
 
175
-**Example 3** Suppose that a friend provides you with a program. She makes sure the program solves the following problem:
175
+**Example 3:** Suppose that a friend provides you with a program. She makes sure the program solves the following problem:
176 176
 
177 177
 `"given three integers, it displays the max value".`
178 178
 
@@ -195,11 +195,11 @@ You could determine if the program provides valid results **without analyzing th
195 195
 If one of these three cases does not have the expected result, your friend's program does not work. On the other hand, if the three cases work, then the program has a high probability of being correct.
196 196
 
197 197
 
198
-####Functions to validate
198
+#### Functions to validate
199 199
 
200 200
 In this exercise you will be designing tests to validate various versions of the functions that are described below. Each one of the functions has four versions, "Alpha", "Beta", "Gamma" and "Delta".
201 201
 
202
-* **3 Sorts:** a function that receives three strings and orders them in lexicographic (alphabetical) order. For example, given `giraffe`, `fox`, and `coqui`, it would order them as: `coqui`, `fox`, and `giraffe`. To simplify the exercise, we will be using strings with lowercase **letters**. Figure 5 shows the function's interface. Notice there is a menu to select the implemented version.
202
+* **3 Sorts:** A function that receives three strings and orders them in lexicographic (alphabetical) order. For example, given `giraffe`, `fox`, and `coqui`, it would order them as: `coqui`, `fox`, and `giraffe`. To simplify the exercise, we will be using strings with **lowercase letters**. Figure 5 shows the function's interface. Notice there is a menu to select the implemented version.
203 203
 
204 204
     ---
205 205
 
@@ -210,7 +210,7 @@ In this exercise you will be designing tests to validate various versions of the
210 210
     ---
211 211
 
212 212
 
213
-* **Dice:** when the user presses the `Roll them!` button, the program generates two random integers between 1 and 6. The program informs the sum of the two random integers.
213
+* **Dice:** When the user presses the `Roll them!` button, the program generates two random integers between 1 and 6. The program informs the sum of the two random integers.
214 214
 
215 215
     ---
216 216
 
@@ -221,7 +221,7 @@ In this exercise you will be designing tests to validate various versions of the
221 221
     ---
222 222
 
223 223
 
224
- * **Rock, Paper, Scissors:** each one of the players enters their play and the program informs who the winner is. Figure 7 shows the options where one object beats the other. The game's interface is shown in Figure 8.
224
+ * **Rock, Paper, Scissors:** Each one of the players enters their play and the program informs who the winner is. Figure 7 shows the options where one object beats the other. The game's interface is shown in Figure 8.
225 225
 
226 226
      ---
227 227
 
@@ -253,7 +253,7 @@ In this exercise you will be designing tests to validate various versions of the
253 253
     ---
254 254
 
255 255
 
256
-####Instructions
256
+#### Instructions
257 257
 
258 258
 1. For each of the functions described above, write in your notebook the tests that you will do to determine the validity of each implementation (Alpha, Beta, Gamma and Delta). For each function, think of the logical errors that the programmer could have made and write tests that determine if these errors were made. For each test, write the values that you will use and the expected result.
259 259
 
@@ -276,17 +276,18 @@ In this exercise you will be designing tests to validate various versions of the
276 276
 You can see examples of how to organize your results [here](http://i.imgur.com/ggDZ3TQ.png) and [here](http://i.imgur.com/rpApVqm.png).
277 277
 
278 278
 
279
-###Exercise 2: Doing tests “by hand”
279
+### Exercise 2: Doing tests “by hand”
280 280
 
281 281
 The `testing` project implements several versions of each of the four functions that were described in Exercise 1. Some or all of the implementations could be incorrect. Your task is, using the tests you designed in Exercise 1, to test the versions for each function to determine which of them, if any, are implemented correctly.
282 282
 
283 283
 This exercise **DOES NOT require programming**, you should make the tests **without looking at the code.**
284 284
 
285
-####Instructions
285
+#### Instructions
286 286
 
287 287
 1. Load the project  `Testing` into `QtCreator`. There are two ways to do this:
288 288
 
289 289
     * Using the virtual machine: Double click the file `Testing.pro` located in the folder `/home/eip/labs/testing-testing` of your virtual machine.
290
+    
290 291
     * Downloading the project’s folder from `Bitbucket`: Use a terminal and write the command `git clone http:/bitbucket.org/eip-uprrp/testing-testing` to download the folder `testing-testing` from `Bitbucket`. Double click the file `Testing.pro` located in the folder that you downloaded to your computer.
291 292
 
292 293
 2. Configure the project and run the program. You will see a window similar to the following:
@@ -305,13 +306,13 @@ This exercise **DOES NOT require programming**, you should make the tests **with
305 306
 
306 307
 
307 308
 
308
-###Exercise 3: Using `assert` to make unit tests
309
+### Exercise 3: Using `assert` to make unit tests
309 310
 
310
-Doing tests by hand each time you run a program is a tiresome task. In the previous exercises you did it for a few simple functions. Imagine doing the same for a complex program like a search engine or a word processor.
311
+Doing tests by hand each time you run a program is a tiresome task. In the previous exercises you did it for a few simple functions. Imagine doing the same for a complex program like a search engine or a word processor!
311 312
 
312 313
 *Unit tests* help programmers validate code and simplify the process of debugging while avoiding having to do these tests by hand in each execution.
313 314
 
314
-####Instructions:
315
+#### Instructions:
315 316
 
316 317
 1. In the `QtCreator` menu, go to `Build` and select `Clean Project "Testing"`. Then go to `File` and select `Close Project "Testing"`.
317 318
 
@@ -323,7 +324,7 @@ Doing tests by hand each time you run a program is a tiresome task. In the previ
323 324
 
324 325
     Your task is to write unit tests for each of the functions to identify the erroneous results. **You do not need to rewrite the functions to correct them.**
325 326
 
326
-    For the `fact` function, a `test_fact()` is provided as a unit test function. If you invoke the function from `main`, compile and run the program you should obtain a message like the following:
327
+    For the `fact` function, a `test_fact()` is provided as a unit test function. If you invoke the function from `main`, compile, and run the program, you should obtain a message like the following:
327 328
 
328 329
      `Assertion failed: (fact(2) == 2), function test_fact, file ../UnitTests/ main.cpp, line 69.`
329 330
 
@@ -341,11 +342,11 @@ Doing tests by hand each time you run a program is a tiresome task. In the previ
341 342
 
342 343
 ---
343 344
 
344
-##Deliverables
345
+## Deliverables
345 346
 
346
-1. Use "Deliverable 1" in Moodle to hand in the table with the tests you designed in Exercise 1 and that you completed in Exercise 2 with the results from the function tests.
347
+1. Use "Deliverable 1" in Moodle to turn in the table with the tests you designed in Exercise 1 and that you completed in Exercise 2, with the results from the function tests.
347 348
 
348
-2. Use "Deliverable 2" in Moodle to hand in the `main.cpp` file that contains the `test_isALetter`, `test_isValidTime`, `test_gcd` functions and their calls. Remember to use good programming techniques, include the name of the programmers involved and document your program.
349
+2. Use "Deliverable 2" in Moodle to turn in the `main.cpp` file that contains the `test_isALetter`, `test_isValidTime`, `test_gcd` functions and their calls. Remember to use good programming techniques by including the name of the programmers involved and documenting your program.
349 350
 
350 351
 ---
351 352