Definitions in testing context (treating “positive” as “test reports a bug/failure”):

True positive : System has a bug; test correctly fails.

False positive : System is correct; test fails (reports a bug that isn’t actually a bug).

True negative : System has a bug; test correctly passes indicating “no success” in detection context (less common phrasing here).

False negative : System has a bug; test incorrectly passes (missed bug).

Here:

The real requirement , as stated, is to verify the existence of the checkout button .

The button still exists ( < button > Checkout < /button > ), so the system behavior is correct regarding that requirement.

The test, however, is checking for an overly specific condition (class= " blue " ), which is not actually part of the stated requirement.

The test fails , saying there is a problem (no button with class= " blue " ), even though from the requirement standpoint, the checkout button is present.

So:

No real bug concerning presence of checkout button.

Test reports a failure → a false positive .

Therefore, the correct category is D, False positive.

The correct answer is C , after correcting the option text to match the actual code.

The object is created here:

let student = new GraduateStudent( " Jane " );

Because GraduateStudent extends Student, its constructor runs:

constructor(name) {

super(name);

this._name = " Graduate Student " + name;

}

The call to:

super(name);

runs the parent Student constructor first and temporarily sets:

this._name = " Jane " ;

Then this line in the child constructor overwrites that value:

this._name = " Graduate Student " + name;

So the final value of this._name becomes:

" Graduate Student Jane "

Next, this line executes:

student.displayGrade();

Since student is an instance of GraduateStudent, JavaScript uses the overridden displayGrade() method from GraduateStudent, not the parent method from Student.

The executed method is:

displayGrade() {

console.log(`${this._name} got 100% on test.`);

}

Therefore, the console output is:

Graduate Student Jane got 100% on test.

Important correction: the original option C said something like " Better student Jackie got 100% on test. " , but the actual code uses " Graduate Student " and the name " Jane " . The verified corrected answer remains C .

There are two valid ways to ensure leo.roar() exists:

Directly assign a roar function to leo (Option A). Assigning a property to an instance object creates a new method on that instance.

leo.roar = () = > { console.log( ' They\ ' re pretty good! ' ); };

After this, calling leo.roar() is valid.

Copy tony’s properties into leo using Object.assign (Option B). Object.assign(target, source) copies enumerable own properties from the source object into the target object. Since tony.roar exists, executing:

Object.assign(leo, tony);

copies roar into leo, making leo.roar() valid.

Why the other answers are incorrect:

Option C: Object.assign(leo, Tiger) copies properties from the function object Tiger , not from Tiger.prototype and not from a Tiger instance. Tiger (the function) has no roar property, so nothing useful is copied.

Option D: leo.prototype is undefined because leo is an instance, not a constructor function. Only constructor functions have a .prototype property. This line would cause an error.

JavaScript Knowledge References (text-only)

Instances have their own properties and do not contain a .prototype property.

Object.assign(target, source) copies own enumerable properties of the source object.

Assigning a function as a property of an object creates a callable method.

==================================================

Semantic versioning: MAJOR.MINOR.PATCH

MAJOR: incompatible API changes.

MINOR: add functionality in a backward compatible manner.

PATCH: backward compatible bug fixes.

Here:

Bug fixes only, no breaking changes → increment PATCH.

From 2.1.1 to 2.1.2.

So the correct new version is 2.1.2.

In JavaScript, NaN has some special properties:

NaN is not equal to anything, including itself.

Equality operators (==, ===) do not work for detecting NaN.

Check each option:

A. value === Number.NaN

Number.NaN is just NaN.

But NaN === NaN is always false.

So this expression is never true and cannot be used to detect NaN.

B. value == NaN

Same issue. NaN == NaN is always false.

So this also never detects NaN.

C. Object.is(value, NaN)

Object.is is a more precise equality comparison method.

It treats NaN as equal to NaN: Object.is(NaN, NaN) is true.

So Object.is(value, NaN) is a valid way to detect NaN.

D. value !== value

Because NaN is the only JavaScript value that is not equal to itself , value !== value is true only when value is NaN.

This is a classic trick for NaN detection.

E. Number.isNaN(value)

Number.isNaN is the recommended modern way to check if a value is NaN without coercion .

It returns true only if value is actually the number NaN.

Therefore, the three correct ways are:

Object.is(value, NaN)

value !== value

Number.isNaN(value)

Understand the three promises:

car1:

let car1 = new Promise((_, reject) = >

setTimeout(reject, 2000, " Car 1 crashed in " )

);

Rejects after 2000 ms (2 seconds) with message " Car 1 crashed in " .

car2:

let car2 = new Promise(resolve = >

setTimeout(resolve, 1500, " Car 2 completed " )

);

Resolves after 1500 ms (1.5 seconds) with message " Car 2 completed " .

car3:

let car3 = new Promise(resolve = >

setTimeout(resolve, 3000, " Car 3 completed " )

);

Resolves after 3000 ms (3 seconds) with message " Car 3 completed " .

Promise.race:

Promise.race([car1, car2, car3])

then(value = > {

let result = `${value} the race.`;

})

catch(err = > {

console.log( " Race is cancelled. " , err);

});

Behavior of Promise.race:

It settles (resolves or rejects) as soon as any of the given promises settles.

It uses the value or reason from the first settled promise.

Timing:

car2 resolves in 1500 ms.

car1 rejects in 2000 ms.

car3 resolves in 3000 ms.

The first to settle is car2 at 1500 ms, with value " Car 2 completed " .

Therefore:

Promise.race resolves (not rejects) with value = " Car 2 completed " .

The .then handler runs; .catch is ignored because there is no rejection.

Inside .then:

let result = `${value} the race.`;

Substitute value:

let result = " Car 2 completed the race. " ;

So, result becomes:

Car 2 completed the race.

Compare to options:

A. Car 3 completed the race.

This would be correct if car3 were the first to resolve, which it is not (it resolves last).

B. Car 2 completed the race.

Exactly matches the first-resolving promise and the constructed message.

C. Race is cancelled.

This is the prefix of the string logged in the .catch handler, but .catch never runs because the race resolves, it does not reject first.

D. Car 1 crashed in the race.

car1 is the first rejection , but since a resolution from car2 happens earlier, the race is already settled successfully before car1 rejects.

Thus the correct value of result as set in the .then block is:

Answer: B

Study Guide / Concept References (no links):

Promise.race(iterable) semantics (first settled promise wins)

setTimeout and timing interactions with Promises

Resolve vs reject paths and .then / .catch

Template literals and string interpolation for building result messages

The answer is B because JavaScript uses lexical scope .

When a function is created inside another function, the inner function can access variables from the outer function where it was defined.

For example:

function first() {

let a = 10;

function second() {

console.log(a);

}

second();

}

Here, a belongs to the outer function first(). The inner function second() can access it because JavaScript looks for variables through the scope chain.

The lookup works like this:

1. Look inside second()

2. If not found, look inside first()

3. If not found, look in the global scope

Since a is found in the outer function’s scope, second() can use it.

This is also the basis of a closure . A closure allows an inner function to remember and access variables from its outer lexical environment.

Why the other options are incorrect:

A is not the best answer because a is not declared inside second() itself.

C is incorrect because the prototype chain is used for object property lookup, not local variable scope lookup.

D is incorrect because hoisting explains how declarations are moved during compilation, but it does not explain why an inner function can access an outer function’s variable.

Therefore, the verified answer is B .

The goal:

" Temporarily and quickly remove them. "

The fastest way is to run a script in the browser console that removes all such elements:

document.querySelectorAll( ' .ad-library-item ' ).forEach(el = > el.remove());

This immediately removes all 50+ elements and requires no page reload.

Option analysis:

A & B : Preventing load events is unreliable and does not remove already-created DOM nodes.

C : Correct—console code can remove all matching DOM elements instantly.

D : Possible but extremely slow; removing 50+ elements one by one in the inspector is not “quick.”

Therefore, C is the best answer.

JavaScript Knowledge References (text-only)

The browser console can run arbitrary JavaScript that manipulates the DOM.

document.querySelectorAll() returns all matching DOM nodes.

Nodes can be removed using .remove().

The correct answers are A, B, and C .

The original variable name appears to contain a typing error. The variable should be used consistently as sampleText:

let sampleText = " The quick brown fox jumps " ;

A is correct because includes() checks whether a string contains a specific substring and returns a Boolean value:

sampleText.includes( ' fox ' );

Since " fox " exists inside " The quick brown fox jumps " , this returns:

true

B is correct after correcting the typing error. The correct expression is:

sampleText.indexOf( ' quick ' ) > -1;

indexOf() returns the index position where the substring is found. If the substring is not found, it returns -1.

Since " quick " exists in the string, sampleText.indexOf( ' quick ' ) returns a value greater than -1, so the expression returns:

true

C is correct after correcting the missing quotation marks and adding a Boolean comparison:

sampleText.indexOf( ' fox ' ) !== -1;

The substring " fox " exists in the string, so indexOf( ' fox ' ) does not return -1. Therefore, the expression returns:

true

D is incorrect because the method name is typed incorrectly. JavaScript string has includes(), not include().

Incorrect:

sampleText.include( ' fox ' )

Correct:

sampleText.includes( ' fox ' )

E is incorrect because JavaScript string matching is case-sensitive:

sampleText.indexOf( ' Quick ' ) !== -1;

The string contains " quick " with a lowercase q, not " Quick " with an uppercase Q, so this returns:

false

Therefore, the verified answers are A, B, and C .

The correct answer is B because countsDeep() is executed inside the callback function passed to setTimeout(), and the try...catch block is also placed inside that same callback.

In JavaScript, setTimeout() schedules a function to run later. The outer code finishes first, and the callback runs asynchronously after the delay. Because of this, a try...catch block placed outside setTimeout() cannot catch errors thrown later inside the callback.

Correct logic:

setTimeout(function() {

try {

countsDeep();

} catch (e) {

handleError(e);

}

}, 1000);

Here, when countsDeep() runs after 1000 milliseconds, any error thrown by countsDeep() happens inside the try block. Therefore, the catch (e) block can catch that error and pass it to handleError(e).

Why the other options are incorrect:

A is incorrect because the syntax is invalid JavaScript. A valid try...catch structure must be:

try {

// code

} catch (e) {

// handle error

}

Option A incorrectly writes:

} handleError (e){

catch(e);

}

That is not valid try...catch syntax.

C is incorrect because the try...catch surrounds only the call to setTimeout(), not the later execution of countsDeep(). If countsDeep() throws an error after the timer expires, the outer catch block will not catch it.

D is incorrect for the same reason as C. In the original question, D also had a typing error: it used countSheep() instead of countsDeep(). Even after correcting that typing error, D is still incorrect because the try...catch is outside the asynchronous callback.