From 8a7dfa0972c83fd811a4296e7373574bea4a28d0 Mon Sep 17 00:00:00 2001
From: Nguyễn Gia Phong <mcsinyx@disroot.org>
Date: Sun, 19 Jul 2020 20:34:40 +0700
Subject: [usth/ICT2.7] Remove Udacity transcribes

---
 .../29 - Review Quiz Solution - lang_en_vs4.srt    | 119 ---------------------
 1 file changed, 119 deletions(-)
 delete mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/29 - Review Quiz Solution - lang_en_vs4.srt

(limited to 'usth/ICT2.7/P4L3 White-Box Testing Subtitles/29 - Review Quiz Solution - lang_en_vs4.srt')

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
deleted file mode 100644
index 1e3228c..0000000
--- a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/29 - Review Quiz Solution - lang_en_vs4.srt	
+++ /dev/null
@@ -1,119 +0,0 @@
-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.
-- 
cgit 1.4.1