Salesforce-JavaScript-Developer Practice Test Questions

Explanation:

This question tests your understanding of variable scoping in JavaScript, specifically the difference between let and var.
Inside the if Block (reassign is true):
let x = 2; creates a new, block-scoped variable x. This variable is separate from the x declared outside the if block. When console.log(x); is called, it accesses this new block-scoped x, which has a value of 2.
var y = 2; re-declares the variable y. Because var is function-scoped, this declaration simply overwrites the value of the y declared outside the if block. When console.log(y); is called inside the if block, it logs the new value, which is 2.

So, the first two console.log statements display 2 and 2.

Outside the if Block:
The first console.log(x); is outside the if block. It references the original x declared with let at the beginning of the function. This variable was not affected by the let x = 2 declaration inside the if block. Therefore, it logs the original value, which is 1.
The second console.log(y); is also outside the if block. Since the var y = 2 declaration inside the if block affected the function-scoped y, this y now holds the value 2. Therefore, it logs 2.

Combining these results, the output is 2 2 1 2.

Explanation:

console.time(label) starts a timer with a given label.
console.timeLog(label) logs the elapsed time since the timer started, without stopping it.
By calling console.timeLog('Performance') after each function, the developer can measure how long each function takes individually.
Example:
console.time('Performance');
maybeAHeavyFunction();
console.timeLog('Performance'); // logs time after first function
thisCouldTakeTooLong();
console.timeLog('Performance'); // logs time after second function
orMaybeThisOne();
console.timeLog('Performance'); // logs time after third function
console.timeEnd('Performance'); // stops timer and logs total

❌ Why the Other Options Are Wrong
B. console.getTime() → ❌ This does not exist in JavaScript.
C. console.trace() → ❌ Logs the stack trace, not performance timing.
D. console.timeStamp() → ❌ Used with performance tools in browsers (like Chrome DevTools) to create timeline markers, not for measuring elapsed execution time.

📖 Reference:
MDN Docs: console.timeLog()
MDN Docs: console.time()
MDN Docs: console.timeEnd()

👉 For this exam style:
If you see "measure elapsed time between calls," the answer is almost always console.timeLog().

Explanation:

The Promise.race() method takes an iterable (like an array) of promises and returns a single promise. This returned promise settles (either fulfills or rejects) as soon as one of the promises in the iterable settles, with the value or reason from that first settled promise.

Let's analyze the timers for each promise:
car1 (line 01): This promise is set to reject after 2000ms (2 seconds) with the value "Car 1 crashed in".
car2 (line 03): This promise is set to resolve after 1500ms (1.5 seconds) with the value "Car 2 completed".
car3 (line 04): This promise is set to resolve after 3000ms (3 seconds) with the value "Car 3 completed".
The execution of Promise.race([car1, car2, car3]) will be determined by which promise settles first.
car2 resolves successfully after 1500ms.
car1 rejects after 2000ms.
car3 resolves after 3000ms.
Since car2 has the shortest timer (1500ms < 2000ms < 3000ms), it settles first. Promise.race() will adopt the state of this first settled promise, which is a fulfillment with the value "Car 2 completed".
Therefore, the .then() handler on line 06 will execute, receiving the value "Car 2 completed". The variable result will be set to the string "Car 2 completed the race." (Note: The code uses a template literal `$(value) the race.`; which is syntactically incorrect—it should be `${value} the race.`;—but the intent is clear for the purpose of the question).

Why the other options are wrong:
A. Car 3 completed the race: This is incorrect because car3 has the longest timer (3000ms) and will be the last to settle. Promise.race() does not wait for it.
B. Car 1 crashed in the race: This is incorrect because while car1 does reject, it does so after 2000ms. car2 resolves 500ms earlier, so its resolution is the one that wins the "race".
D. Race is cancelled.: This is the message that would be logged in the .catch() handler. The .catch() handler would only run if the first settled promise was a rejection. Since the first settled promise (car2) was a fulfillment, the .then() handler runs instead of the .catch() handler.

Explanation:

FileReader is the correct API to read local files selected by a user via < input type= " file" >.
reader.readAsDataURL(file) reads the file as a Base64-encoded Data URL, which can be assigned directly to an src attribute to display the image.
The "load" event listener ensures that once the file is fully read, reader.result contains the file’s data, which is then used for preview. So the full working version is:
function previewFile() {
const preview = document.querySelector('img');
const file = document.querySelector('input[type=file]').files[0];
const reader = new FileReader(); // ✅ correct object

reader.addEventListener("load", () => {
preview.src = reader.result; // ✅ set preview
}, false);

if (file) {
reader.readAsDataURL(file); // ✅ convert file into Data URL
}
}


❌ Why Other Options Are Wrong
A. const reader = new File(); → ❌ File is not used this way; it represents file objects, not readers. URL.createObjectURL(file) can create blob URLs, but then you don’t need FileReader at all (and the snippet relies on reader.result).
C. const reader = new File(); + reader.readAsDataURL(file) → ❌ Invalid because File objects don’t have .readAsDataURL(). That’s only for FileReader.

📖 Reference:
MDN: FileReader
MDN: readAsDataURL()

💡 Quick Exam Tip:
If you see reader.result → always think FileReader + readAsDataURL() for image previews.

Explanation:

The special value NaN (Not-a-Number) has the unique property that it is the only value in JavaScript that is not equal to itself. This quirk is the basis for the most reliable detection methods.

Let's evaluate each option:
B. Object.is(value, NaN)
The Object.is() method is a reliable way to check if two values are the same. It is designed to correctly identify NaN values. Object.is(NaN, NaN) returns true.
This is a correct method.

D. value !== value
This is a classic and reliable idiom for detecting NaN. Since NaN is the only value that is not equal to itself, this comparison will only return true if the value is NaN.
This is a correct method.

E. Number.isNaN(value)
This is the modern, built-in function specifically designed for this purpose. Unlike the global isNaN(), Number.isNaN() does not perform type coercion. It only returns true if the provided value is exactly the NaN value (type number).
This is a correct method.

Why the other options are wrong:
A. value == NaN
This comparison will always return false. Due to the fundamental rule that NaN is not equal to anything, including itself, this check is useless. It will never find an NaN value.
C. value === Number.NaN
While Number.NaN is simply a reference to the global NaN value, using the strict equality operator (===) with NaN is still unreliable. The rule NaN !== NaN still applies, so this comparison will also always return false.

Reference:
MDN Web Docs: Number.isNaN()
MDN Web Docs: Object.is()
MDN Web Docs: NaN - Specifically notes: "NaN compares unequal (via ==, !=, ===, and !==) to any other value -- including to another NaN value."

Explanation:

This question pertains to ES6 module syntax for importing and exporting functionality in JavaScript.
Importing all exports: The import * as name syntax is used to import all named exports from a module and bundle them into a single object. In this case, * signifies "all exports," and as lib creates a local object named lib to hold all of these exports. This object then acts as a namespace for the imported functions.
Correct Syntax: import * as lib from '...';
Calling the functions: Once all the functions are bundled into the lib object, you can access them using dot notation (.) on that object.
Correct Calls: lib.foo(); and lib.bar();

Why other options are incorrect:
B: import {foo, bar} from '...'; is used for named imports. It would be correct if you only wanted to import foo and bar individually, but it doesn't match the "import every function" part of the question. Also, the function calls would be foo() and bar() directly, not through a namespace.
C: import all from '...'; is not valid ES6 module syntax for importing all exports. import all is not a recognized keyword or pattern.
D: import * from '...'; is invalid syntax. The * must be followed by as name to create a namespace object. You cannot call functions directly on the module path or a non-existent global object like universalContainersLib.

In summary, the import * as name syntax is the standard way to import all named exports from a module and access them via a single namespace object.

Explanation:

At the moment the code pauses at debugger, the browser console gives you access to everything that’s been declared and initialized before that line. That means:
carSpeed has already been assigned using document.getElementById('CarSpeed'), so you can inspect its value — which is a DOM element.
You can also explore that DOM element’s properties, including its styles, attributes, and any event listeners attached to it.

However:
fourWheels hasn’t been created yet — it’s declared after the debugger line — so it won’t be available until you step forward in execution.
JavaScript doesn’t automatically track how many instances of an object have been created unless you explicitly code for it.
window.localStorage is always accessible, but it’s not directly tied to this code or breakpoint unless you’re interacting with it.

So the two correct answers are:
A. The values of the carSpeed and fourWheels variables — partially true, but only carSpeed is available at the breakpoint.
C. The style, event listeners and other attributes applied to the carSpeed DOM element — absolutely true and inspectable.

Explanation:

White box testing (C)
White box means the test has visibility into the internal workings of the code.
In this scenario, you aren’t just checking the output — you’re specifically verifying how many times query() was called and with what arguments. That’s examining the implementation details, which is classic white-box behavior.

Mocking (D)
A mock object is a test double that simulates a real dependency and records interactions.
Here, the database object with a query method returning an array is a mock.
It lets the developer verify:
How many times it was called.
With what arguments.
This exactly matches the requirement.

❌ Why the Others Are Wrong
A. Integration → ❌ An integration test checks how real components work together (e.g., real database queries). Here, the dependency is replaced (mocked), so this is not integration testing.
B. Black box → ❌ Black box testing only checks inputs/outputs without looking at internals. Since the requirement is to count function calls and arguments, that’s internal behavior → not black box.

📖 Reference
MDN: Mock functions (Jest docs, applies to JS testing)
Salesforce Developer Guide: Testing Best Practices
General Testing Theory: White-box vs Black-box

💡 Quick Exam Tip:
If a question mentions counting function calls, arguments, or verifying interactions → the answers are almost always White Box + Mocking.

Explanation:

The import statement import {foo, bar} from '/path/Utils.js'; is a named import. It expects the module Utils.js to export multiple specific values using named exports. Let's analyze the options:

B. const foo = () => { return ‘foo’ ; } const bar = () => { return ‘bar’ ; } export { bar, foo }
This code creates two functions and then exports them explicitly using the export { ... } syntax. This creates the necessary named exports foo and bar. The import statement import {foo, bar} ... will successfully import these two specific functions.
This is a correct implementation.

C. Export default class { foo() { return ‘foo’ ; } bar() { return ‘bar’ ; } }
This code uses a default export. It exports a single class as the default export. The methods foo and bar are inside this class. To use them, the import syntax would need to be completely different. The correct import would be:
import MyClass from '/path/Utils.js';
let instance = new MyClass();
instance.foo();
instance.bar();

The original import statement import {foo, bar} ... would fail because there are no named exports called foo and bar; there is only one default export (a class).
This is an incorrect implementation for the given import statement.

Why the other options are wrong:
A. // FooUtils.js and BarUtils.js exist Import (foo) from ‘/path/FooUtils.js’; Import (boo) from ‘ /path/NarUtils.js’;
This option is not valid JavaScript syntax for a module file. It attempts to use an import statement inside another module without re-exporting the values. Furthermore, it imports boo from the second file but doesn't show it being exported from Utils.js. The original import expects both foo and bar to come from a single file, Utils.js.
This is an incorrect implementation.

D. const foo = () => { return ‘foo’;} const bar = () => {return ‘bar’; } Export default foo, bar;
This code attempts to use a default export incorrectly. The export default syntax can only take a single value following it (e.g., export default foo;). The syntax export default foo, bar; is invalid and would result in an error. To export multiple values, named exports (as in option B) must be used.
This is an incorrect implementation.

Reference:
MDN Web Docs: Export - Named exports
MDN Web Docs: Export - Default exports

The key distinction is that the original import uses braces {foo, bar}, which means it is looking for named exports, not a default export. Only option B provides the correct named exports.

Explanation:

Execution Timeline
Immediately →
logCounter() runs.
Logs: 0

At ~1000ms →
setInterval fires the first time:
counter increments from 0 → 1
logCounter() logs 1

At ~1100ms → setTimeout(logCounter, 1100) fires:
counter is still 1
logs 1

At ~2000ms →
setInterval fires again:
counter increments from 1 → 2
logCounter() logs 2
✅ First Four Logs
0, 1, 1, 2
✅ Correct Answer:
C. 0 1 1 2

❌ Why Others Are Wrong
A. 0 0 1 2 → Wrong, because at 1000ms, counter already incremented to 1.
B. 0 1 2 3 → Wrong, too fast; setTimeout at 1100 logs 1, not 2.
D. 0 1 2 2 → Wrong, because the setTimeout doesn’t magically skip ahead; it logs the current value (1).

📖 Reference
MDN: setTimeout()
MDN: setInterval()

💡 Quick Exam Tip:
When both setTimeout and setInterval are near each other, always check:
Which one fires first (intervals at multiples of 1000ms, timeout at 1100ms).
The variable’s value at that exact time.