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

Explanation:
This question tests your understanding of executing asynchronous functions and handling promises in JavaScript. The runParallel() function is declared as async, which means it returns a Promise. To execute it and access the resolved value, you must call it and handle the returned promise using .then() with a callback function. The .then() method expects a function as its argument, and data (the resolved value) is passed to that callback. The syntax must be correct for the promise chain to work.

Correct Options:

B. runParallel().then(function(data){ return data; }); –
Correct. This correctly calls runParallel(), which returns a Promise. The .then() method is called with a proper callback function that receives the resolved value (data). The callback returns the data, which could be used in further chaining. This is valid and standard promise handling syntax.

D. runParallel().then(data); –
Correct. In JavaScript, .then() accepts a function reference. Since data is a variable (presumably defined elsewhere as a function), passing data directly to .then() is valid as long as data is a function. In the context of the question, this implies data is a defined callback function. This is a concise way to pass a function reference to .then().

Incorrect Options:

A. async runParallel().then(data); –
Incorrect. The async keyword is used only when declaring a function, not when calling it. Placing async before a function call is a syntax error. The correct call is simply runParallel().then(data);. The async keyword is already part of the function declaration (line 04), so it should not be repeated during invocation.

C. runParallel().done(function(data){ return data; }); –
Incorrect. There is no .done() method on a Promise in standard JavaScript. While some older libraries (like jQuery) have a .done() method, native JavaScript promises only support .then(), .catch(), and .finally(). This would throw a TypeError because .done() does not exist.

Reference:

MDN Web Docs – async function and return value

MDN Web Docs – Promise.prototype.then() method

MDN Web Docs – Using promises and chaining

MDN Web Docs – async/await syntax and execution

Salesforce Trailhead – JavaScript Essentials: Asynchronous Programming and Promises

Explanation:
This question tests your understanding of EventEmitter-based APIs in Node.js, specifically how to set up event listeners for connection and error events. Client libraries built with events and callbacks typically use the .on() method to register listeners for specific events. The connection is established when the library internally triggers the 'connect' event, and errors are emitted as 'error' events. The developer should attach listeners before or at execution time using .on() to handle these events properly. Using .connect() with callbacks or try/catch is not the correct pattern for event-driven libraries.

Correct Option:

B.
javascript
ws.on('connect', () => {
console.log('Connected to client');
});
ws.on('error', (error) => {
console.log('ERROR', error);
});

This is correct. The library is built using events and callbacks, so the standard pattern is to use .on() to register event listeners for 'connect' and 'error'. The 'connect' event fires when the WebSocket connection is successfully established, and the 'error' event fires when a connection failure or other error occurs. This approach correctly listens for these events at execution time without interfering with the connection establishment process.

Incorrect Options:

A. ws.connect(() => { console.log('Connected to client'); }).catch((error) => { console.log('ERROR', error); }); –
Incorrect. This syntax suggests a Promise-based approach with .connect() returning a Promise and using .catch() for errors. However, the problem states the library is built using events and callbacks, not Promises. The .connect() method is likely not a Promise-returning function, and .catch() would not be available. This pattern is not appropriate for EventEmitter-based libraries.

C. (Appears identical to option B in the prompt, but the answer key indicates B is correct. This may be a duplicate or formatting issue in the question. Assuming C is different in the original exam, it would be incorrect if it uses a different pattern or syntax.

D. try { ws.connect(() => { console.log('Connected to client'); }); } catch(error) { console.log('ERROR', error); } –
Incorrect. This uses a synchronous try/catch block around an asynchronous .connect() call. Errors from event-driven libraries are emitted as 'error' events, not thrown as synchronous exceptions. Therefore, the catch block would never capture connection failures. Additionally, this approach does not set up the proper event listeners for the 'error' event.

Reference:

Node.js Official Documentation – Events (EventEmitter)

Node.js Official Documentation – Error events and event handling

MDN Web Docs – EventEmitter pattern in Node.js

Salesforce Trailhead – Node.js Development: Event-Driven Programming

Explanation:
This question tests your understanding of prototype inheritance and method overriding in JavaScript. The Item constructor creates regular items, and SaleItem is a subclass (presumably inheriting from Item). On line 03, a description method is added to Item.prototype, making it available to all instances of Item and its subclasses. On line 07, SaleItem.prototype.description is defined, overriding the inherited method specifically for SaleItem instances. Since both methods are added to the respective prototypes before the calls on lines 08 and 09, all method lookups succeed, and the correct descriptions are logged.

Correct Option:

B.
text
This is a Scarf
This is a Shirt
This is a Scarf
This is a discounted Shirt
This is correct. Let's trace execution:
Line 03 adds description to Item.prototype. Both regItem and saleItem inherit this method.
Line 04: regItem.description() uses the prototype method → logs 'This is a Scarf'.
Line 05: saleItem.description() uses the inherited Item.prototype.description (since SaleItem.prototype hasn't been overridden yet) → logs 'This is a Shirt'.
Line 07: SaleItem.prototype.description is defined, overriding the inherited method for SaleItem instances.
Line 08: regItem.description() still uses Item.prototype.description (unaffected) → logs 'This is a Scarf'.
Line 09: saleItem.description() now uses the overridden method on SaleItem.prototype → logs 'This is a discounted Shirt'.

Incorrect Options:

A. – Incorrect.
This option suggests that saleItem.description() throws an error on line 05. However, saleItem inherits description from Item.prototype (line 03) before the override on line 07, so it is a function and executes successfully. The error does not occur.

C. – Incorrect.
This option also suggests an error on line 05, which is not the case. Additionally, the second regItem.description() call (line 08) would log correctly. The error is imagined because SaleItem.prototype does not yet have its own description at line 05, but it inherits from Item.prototype.

D. – Incorrect.
This option suggests that after line 07, regItem.description() logs 'This is a discounted Scarf'. However, overriding SaleItem.prototype.description does not affect regItem because regItem is an instance of Item, not SaleItem. The prototype chain for regItem does not include SaleItem.prototype, so it remains unchanged.

Reference:

MDN Web Docs – Inheritance and the prototype chain

MDN Web Docs – Object.prototype and prototype property

MDN Web Docs – Method overriding in JavaScript

Salesforce Trailhead – JavaScript Essentials: Object-Oriented Programming and Prototypes

Explanation:
This question tests your understanding of nested try...catch...finally blocks and how they affect variable assignments and error propagation. The inner try block throws an error on line 05, which is caught by the inner catch block. Inside the inner catch, first is changed to 'Why', and then the error is re-thrown using throw err. The finally block executes after the catch completes but before the error propagates out, setting second to 'When'. The re-thrown error is then caught by the outer catch block, which changes second to 'Where'. The final values are first = 'Why' and second = 'Where'.

Correct Option:

B. first is Why and second is Where. – Correct. Let's trace the execution step by step:

Line 01: first = 'Who'

Line 02: second = 'What'

Inner try (line 04): throws new Error('Sad trombone')

Inner catch (line 06-08): catches the error, sets first = 'Why', then re-throws the same error with throw err

Inner finally (line 09-10): executes after the catch but before the error propagates out, setting second = 'When'

The re-thrown error propagates to the outer catch (line 12-13)

Outer catch sets second = 'Where'

Final values: first = 'Why', second = 'Where'

Incorrect Options:

A. first is Who and second is Where. –
Incorrect. The inner catch block executes and changes first to 'Why' before re-throwing the error. The finally block then sets second to 'When', but the outer catch overrides it to 'Where'. So first is not 'Who'; it is 'Why'.

C. first is Who and second is When. –
Incorrect. This ignores both the inner catch (which changes first to 'Why') and the outer catch (which changes second to 'Where'). The finally block sets second = 'When', but the outer catch executes after the finally and overrides it to 'Where'.

D. first is Why and second is When. –
Incorrect. While first is correctly 'Why', second is not 'When'. The outer catch executes after the inner finally and changes second to 'Where'. The finally block's assignment is overwritten by the outer catch.

Reference:

MDN Web Docs – try...catch...finally statement and execution order

MDN Web Docs – Nested try...catch blocks

MDN Web Docs – throw statement and error propagation

Salesforce Trailhead – JavaScript Essentials: Error Handling and Control Flow

Explanation:
This question tests your understanding of using browser developer tools to manipulate the DOM for temporary debugging or testing purposes. The developer wants to quickly and temporarily remove all

Explanation:
This question tests your knowledge of event listeners and controlling how many times a handler executes. The requirement is that the message should be displayed only on the first click, not on subsequent clicks. There are two standard approaches to achieve this: using the once option in addEventListener(), which automatically removes the listener after it fires once, or manually removing the listener inside the handler using removeEventListener(). Both approaches ensure that the handler executes only once.

Correct Options:

C. On line 06, add an option called once to button.addEventListener(). –
Correct. The addEventListener() method accepts an optional third parameter, which can be an options object with a once property. Setting { once: true } ensures that the listener is automatically removed after it is invoked once. This is a clean and modern way to achieve the desired behavior without modifying the handler function. Line 06 should be: button.addEventListener('click', listen, { once: true });

D. On line 04, use button.removeEventListener('click', listen); –
Correct. Inside the listen function, after displaying the alert, the developer can manually remove the event listener using removeEventListener(). This prevents the handler from being called on subsequent clicks. This is a valid and widely used approach, though it requires that the same function reference (not an anonymous function) is passed to both addEventListener and removeEventListener.

Incorrect Options:

A. On line 04, use event.stopPropagation(); –
Incorrect. The stopPropagation() method prevents the event from bubbling up the DOM tree to parent elements. It does not prevent the current listener from being called again on future clicks. It only affects event propagation during the current event cycle, not the number of times the listener executes.

B. On line 02, use event.first to test if it is the first execution. – Incorrect. There is no first property on the Event object in JavaScript. The Event interface does not provide any built-in mechanism to track whether a listener has been called before. This property does not exist, so it would evaluate to undefined and would not solve the problem.

Reference:

MDN Web Docs – EventTarget.addEventListener() (once option)

MDN Web Docs – EventTarget.removeEventListener() method

MDN Web Docs – Event.stopPropagation() method

MDN Web Docs – Event interface and properties

Salesforce Trailhead – JavaScript Essentials: Working with Events and Event Listeners

Explanation:
This question tests your understanding of asynchronous JavaScript, specifically the event loop, setTimeout, and async/await behavior. When the code executes, synchronous code runs first. The console.log(2) on line 10 executes immediately, logging 2. Then asyncCall() is invoked, which calls delay(1000), scheduling a timer that will resolve after 1000ms. However, await pauses the execution of asyncCall() but does not block the main thread. The synchronous console.log(3) on line 12 executes immediately after asyncCall() is called, logging 3. After the timer completes (1000ms later), the promise resolves, and console.log(1) is logged. Therefore, the order is 2, 3, 1.

Correct Option:

D. 2 3 1 – Correct. Let's trace the execution step by step:

Line 10: console.log(2) executes synchronously → logs 2.

Line 11: asyncCall() is invoked. Inside asyncCall, await delay(1000) is called.

delay(1000) schedules a setTimeout for 1000ms and returns a pending Promise.

The await keyword pauses the execution of asyncCall and returns control to the caller.

Line 12: console.log(3) executes synchronously → logs 3 (while the timer is still pending).

After 1000ms, the setTimeout callback resolves the promise, and asyncCall resumes.

console.log(1) executes → logs 1.

Final output order: 2, 3, 1.

Incorrect Options:

A. 1 2 3 –
Incorrect. This would imply that console.log(1) executes before console.log(2), but console.log(2) is synchronous and runs immediately. The asyncCall() function is asynchronous and its console.log(1) is delayed by the setTimeout, so it cannot appear before 2.

B. 1 3 2 –
Incorrect. This incorrectly places 1 first, but 1 is delayed by the 1000ms timer and cannot log before the synchronous 2 and 3. The synchronous code always executes before asynchronous callbacks.

C. 2 1 3 –
Incorrect. This incorrectly places 1 before 3. The await inside asyncCall pauses the function but does not block the main thread, so console.log(3) executes immediately after asyncCall() is invoked, before the timer resolves. Therefore, 3 must appear before 1.

Reference:

MDN Web Docs – async/await and the event loop

MDN Web Docs – setTimeout and asynchronous callbacks

MDN Web Docs – Promise and microtask/task queue

Salesforce Trailhead – JavaScript Essentials: Asynchronous Programming and Event Loop

Explanation:
This question tests your knowledge of ES6 module import syntax, specifically namespace imports. When a developer wants to import every function from a module and then call functions from it, the correct approach is to use a namespace import with the * as syntax. This imports all named exports from the module as properties of a single object (the namespace). The developer can then call lib.foo() and lib.bar() using that object. Other import styles either import specific named exports, use invalid syntax, or do not provide a namespace object for calling functions.

Correct Option:

A.

javascript

import * as lib from '/path/universalContainerslib.js';

lib.foo();

lib.bar();

This is correct. The import * as lib syntax imports all named exports from the module and binds them to the namespace object lib. This allows the developer to access any exported function (including foo and bar) as properties of lib, such as lib.foo() and lib.bar(). This is the standard way to import an entire module's exports when you need to call multiple functions from it.

Incorrect Options:

B. import * from '/path/universalContainerslib.js'; universalContainerslib.foo(); universalContainerslib.bar(); –
Incorrect. The import * from syntax is invalid in JavaScript. The correct syntax for a namespace import requires the as keyword to specify a namespace name (e.g., import * as lib from ...). Additionally, universalContainerslib is not defined as a variable, so calling universalContainerslib.foo() would throw a ReferenceError.

C. import all from '/path/universalContainerslib.js'; universalContainerslib.foo(); universalContainerslib.bar(); –
Incorrect. The import all from syntax is invalid. The all keyword is not a valid import specifier in ES6 modules. This would throw a syntax error. Additionally, universalContainerslib is not defined, so the function calls would fail even if the import were valid.

D. import {foo, bar} from '/path/universalContainerslib.js'; foo(); bar(); –
Incorrect. This imports only the specific named exports foo and bar, not every function from the module. The requirement states that the developer wants to import every function from the module. This approach only imports the two specified functions and would not provide access to any other exports from the module.

Reference:

MDN Web Docs – import statement (namespace imports)

MDN Web Docs – import * as namespace syntax

MDN Web Docs – Named exports and importing specific exports

Salesforce Trailhead – JavaScript Modules and ES6 Import Syntax

Explanation:
This question tests your understanding of memory efficiency and method creation in JavaScript, specifically the difference between defining methods inside a constructor function versus on the prototype. In Option A, the growl method is defined inside the constructor using this.growl = () => {...}. This creates a new function for every instance created, resulting in 1000 separate growl methods in memory. In Option B, growl is defined on Monster.prototype, which is shared across all instances. All 1000 objects reference the same single growl method on the prototype, resulting in only 1 growl method in memory.

Correct Option:

C. 1000 growl methods are created for Option A. 1 growl method is created for Option B. –
Correct. Option A defines growl as an own property on each instance inside the constructor. Every time new Monster() is called, a new arrow function is created and assigned to this.growl. Therefore, 1000 instances produce 1000 distinct growl functions. Option B defines growl on Monster.prototype. Since the prototype is shared among all instances, only one growl function exists in memory, and all 1000 objects inherit and use that single method.

Incorrect Options:

A. 1000 growl methods are created regardless of which option is used. –
Incorrect. This is only true for Option A. In Option B, the method is placed on the prototype, so it is shared among all instances. Only one growl method is created, not 1000.

B. 1 growl method is created regardless of which option is used. –
Incorrect. This is only true for Option B. In Option A, the method is defined inside the constructor, so a new function is created for each instance. 1000 instances result in 1000 separate growl functions.

D. 1 growl method is created for Option A. 1000 growl methods are created for Option B. –
Incorrect. This reverses the correct behavior. Option A creates a new method per instance (1000 methods), while Option B creates a single shared method on the prototype (1 method). The opposite is stated here.

Reference:

MDN Web Docs – Constructor functions and instance methods

MDN Web Docs – Prototype and shared methods

MDN Web Docs – Memory efficiency in JavaScript objects

Salesforce Trailhead – JavaScript Essentials: Object-Oriented Programming and Prototypes

Explanation:
This question tests your knowledge of debugging and assertion methods in JavaScript, specifically console.assert(). The console.assert() method is designed to log an error message to the console only when the provided condition evaluates to false. It takes a condition as its first argument and an optional message as the second. If the condition is truthy, nothing happens; if falsy, it logs an error. The requirement is to log an error when the Boolean statement evaluates to false, which is exactly what console.assert() does.

Correct Option:

C. console.assert(number + 2 === 0); –
Correct. console.assert() evaluates the condition number + 2 === 0. If the condition is true, nothing is logged. If the condition is false (which it will be for all numbers in the loop except -2, which never occurs), an error message is logged to the console. This meets the requirement to log an error when the Boolean statement evaluates to false.

Incorrect Options:

A. console.classy(number + 2 === 0); –
Incorrect. There is no console.classy() method in JavaScript. This would throw a TypeError because console.classy is undefined. This is not a valid debugging or logging method.

B. assert(number + 2 === 0); –
Incorrect. The assert() function is not a built-in global function in standard JavaScript. While Node.js has an assert module that must be required, and some testing frameworks provide global assert() functions, it is not available in the browser console or in standard JavaScript without importing. This would throw a ReferenceError.

D. console.error(number + 2 === 0); –
Incorrect. console.error() logs a message to the console as an error, but it does not evaluate a Boolean condition. It will always log the result of the expression number + 2 === 0 (which is either true or false) as a value. It will log every time, regardless of whether the condition is true or false, which does not meet the requirement of logging only when the condition is false.

Reference:

MDN Web Docs – console.assert() method

MDN Web Docs – console.error() method

MDN Web Docs – Console API and debugging methods

Salesforce Trailhead – JavaScript Essentials: Debugging and Console Methods