You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
bref="Software testing is an investigation conducted to provide stakeholders with information about the quality of the software product or service under test"
6
+
bref="Software testing is an investigation conducted to provide stakeholders with information about the quality of the software product or service under test. Debugging is the process of finding and resolving defects or problems within a computer program that prevent correct operation of computer software or a system"
TDD is a _design process_, not a testing process. TDD is a robust way of designing software components ("units") interactively so that their behaviour is specified through unit tests.
59
17
@@ -76,4 +34,58 @@ During phase 2, don't bother with quality.
76
34
+ Fast feedback for the developers, you know that you don't break anything and that you are evolving the system in a good direction
77
35
+ Generates confidence to add features, fix bugs, or explore new designs
78
36
79
-
Note that code written without a test-first approach is often very hard to test!
37
+
Note that code written without a test-first approach is often very hard to test!
<dd>Individual units/components of a software are tested. A unit is the smallest testable part of any software. It usually has one or a few inputs and usually a single output. </dd>
46
+
<dt>Integration testing</dt>
47
+
<dd>Individual software modules are combined and tested as a group. </dd>
48
+
<dt>System testing</dt>
49
+
<dd>A complete and integrated software is tested for compliance with the specified requirements. </dd>
50
+
<dt>Acceptance testing</dt>
51
+
<dd>A system is tested for acceptability and ready for delivery. </dd><br/>
<li><b>Syntax or interpretation errors</b> - These include mismatched or missing quotes, parentheses and braces, incorrect case, spelling mistakes, illegal characters, and more. These erros can usually be caught using linters like <ins>ESlint</ins> or <ins>JSLint</ins>. Linters analyze your code before it is executed and point out syntax and other common errors.</li>
72
+
<li><b>Runtime exceptions</b> - These are the errors that occur when your JavaScript code executes. Such errors can be triggered by referring to an undefined variable, dividing by zero, by a failed “assert” statement, or by using a “throw” statement in your (or a JavaScript library’s) code to manually specify that an exception has occurred. When a runtime exception occurs, any JavaScript code after that line of code is not executed so they can leave your web page or application in an unexpected state. You can catch and handle runtime exceptions by wrapping the code that fails with a <mark>try {code}</mark> <mark>catch(exception) {}</mark> block.</li>
73
+
<li><b>Incorrect logic</b> - does not show any errors but causes your code to not do what you intend it to. Debugging such errors requires some practice using debugging tools that your browser provides.</li>
74
+
</ol></dd>
75
+
<dt>Chrome DevTools</dt>
76
+
<dd>
77
+
<ul>
78
+
<li><b>Console</b> - Use <mark>console.log()</mark> to dump statements and other useful information like stack variables. Use <mark>console.assert()</mark> to ensure that certain conditions or assumptions are being met in your code. This also dumps the execution call stack and continues execution after the assert.</li>
79
+
<li><b>Debugger</b> - To specify a breakpoint, click on its line number in your code editor or in the Sources panel in <ins>Chrome DevTools</ins>. This will cause the debugger to pause at that line and allow you to inspect variables, the call stack, and evaluate expressions. With the debugger you can continue execution by stepping over the code line-by-line. You can set <ins>watches</ins> for variables and see how they change as you step over the code line by line. DevTools also has <ins>conditional breakpoints</ins> where you can specify the condition when the debugger stops execution.</li>
80
+
<li><b>Working with APIs</b> - The Networks panel in DevTools shows you, for each network request, the “method” (e.g. GET, POST), the HTTP status code (e.g. 200, 403), the MIMEtype (e.g. application/json), the content’s size and whether the network request was fulfilled from the browser’s cache.</li>
81
+
<li><b>Tips</b> - To ensure that your web page is using the latest version of your code, disable the browser cache in the DevTools settings. Also, when inspecting JavaScript objects, remember to use <mark>console.log(JSON.parse(JSON.stringify(obj)));</mark>.</li>
0 commit comments