Free Salesforce-JavaScript-Developer Practice Test Questions (2026)

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 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:

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.