1 files changed, 119 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/29 - Review Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/29 - Review Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..1e3228c
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/29 - Review Quiz Solution - lang_en_vs4.srt
@@ -0,0 +1,119 @@
+1
+00:00:00,230 --> 00:00:02,520
+And the answer in this case is no. And
+
+2
+00:00:02,520 --> 00:00:05,480
+the reason for this is because this code is
+
+3
+00:00:05,480 --> 00:00:08,950
+unreachable. This is dead code because no matter the
+
+4
+00:00:08,950 --> 00:00:12,560
+value of j, this condition will always be false because
+
+5
+00:00:12,560 --> 00:00:14,770
+i will always be 0. And notice that this
+
+6
+00:00:14,770 --> 00:00:17,670
+is a small example, but another important truth is
+
+7
+00:00:17,670 --> 00:00:22,520
+that any non-trivial program contains dead or unreachable code,
+
+8
+00:00:22,520 --> 00:00:25,610
+code that no matter how well we test our system,
+
+9
+00:00:25,610 --> 00:00:28,450
+we will never be able to exercise. Why is that? Various
+
+10
+00:00:28,450 --> 00:00:31,030
+reasons. For example, defensive programming or,
+
+11
+00:00:31,030 --> 00:00:33,600
+for example, developing for future releases.
+
+12
+00:00:33,600 --> 00:00:36,320
+So there might be pieces of code that are added, but they're
+
+13
+00:00:36,320 --> 00:00:39,380
+still not activated. They're still not invoked by any other part of
+
+14
+00:00:39,380 --> 00:00:41,970
+the code because of modifications to the code. There are some
+
+15
+00:00:41,970 --> 00:00:44,480
+parts that were executed before and in the new version of the
+
+16
+00:00:44,480 --> 00:00:47,915
+program, they are no longer exercised. They are no longer executable. But
+
+17
+00:00:47,915 --> 00:00:50,760
+they still remain in the code base. And this is a very,
+
+18
+00:00:50,760 --> 00:00:54,560
+very normal situation for this reason and many more. And this is
+
+19
+00:00:54,560 --> 00:00:56,790
+an important concept because this affects
+
+20
+00:00:56,790 --> 00:00:58,760
+the very meaning of coverage measures. If
+
+21
+00:00:58,760 --> 00:01:01,225
+there is some unreachable code, we will never be able to reach
+
+22
+00:01:01,225 --> 00:01:04,709
+100% code coverage. And in fact, if you remember, at the beginning of
+
+23
+00:01:04,709 --> 00:01:07,380
+the lesson, we discussed this concept and asked you why you think
+
+24
+00:01:07,380 --> 00:01:10,470
+that, in the industry, the target for coverage is not 100% but less
+
+25
+00:01:10,470 --> 00:01:12,850
+that that. And that's the answer, to account for the fact that there
+
+26
+00:01:12,850 --> 00:01:15,890
+are infeasibility problems that I have to take into account when I test
+
+27
+00:01:15,890 --> 00:01:19,920
+the code, infeasible paths, unexecutable statements, conditions that can never
+
+28
+00:01:19,920 --> 00:01:22,780
+be true, and so on. So most criteria, if not
+
+29
+00:01:22,780 --> 00:01:24,620
+all, are affected, and we need to take that into
+
+30
+00:01:24,620 --> 00:01:27,270
+account when we try to achieve a given coverage target.