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

Explanation:
This question tests understanding of closures and higher-order functions in JavaScript. The code pattern shows addBy being called with 8 (returning a function), then that returned function is called with 50 to produce 58. This requires addBy to be a function that returns another function which captures the first argument (num1) and adds it to the second argument (num2) when invoked.

Correct Options:

A – Correct.
This defines addBy as a function that takes num1 and returns a new function that takes num2 and returns num1 + num2. When addBy(8) is called, it returns function(num2) { return 8 + num2; }. Then addByEight(50) adds 8 + 50 = 58. This is a proper closure implementation.

D – Correct.
This is the arrow function equivalent of option A. addBy is defined as an arrow function that takes num1 and returns an inner function (using traditional function syntax) that takes num2 and returns num1 + num2. It works identically to option A, creating a closure that captures num1 and returns 58 when called with 50.

Incorrect Options:

B – Incorrect.
This function takes only one parameter num1 but tries to use num2 which is not defined in its scope. This would throw a ReferenceError because num2 is not accessible. Additionally, it doesn't return a function as required by the pattern.

C – Incorrect.
This arrow function (num1) => num1 + num2 also tries to reference num2 which is not defined in its scope. It would throw a ReferenceError. Moreover, it doesn't return a function, so addBy(8) would return a number (or error), not a function that can be called with 50.

Reference:
MDN Web Docs - Closures and Function returning functions; Salesforce LWC JavaScript documentation on higher-order functions and closures.

Explanation:
This question tests your knowledge of ES6 module syntax, specifically the difference between default and named imports. In JavaScript, when you import a module without curly braces ({}), you are explicitly importing the default export from that module. The naming of the imported variable is flexible because it refers to the default binding.

Correct Option:

C. printPrice must be the default export
This is correct because import printPrice from '...' uses the default import syntax. In the exported file (PricePrettyPrint.js), the code must contain export default followed by a function, class, or object. Default imports do not require curly braces and can be assigned any local name. The file likely exports export default function printPrice() {...} or similar.

Incorrect Option:

A. printPrice must be a named export –
Incorrect. Named exports require curly braces during import, e.g., import { printPrice } from '...'. Without the braces, the JavaScript engine looks for a default export only. A named export would cause a runtime error because no default binding exists.

B. printPrice must be an all export –
Incorrect. "All export" is not a standard ES6 term. This likely confuses with export * or namespace imports (import * as), which are not applicable here. Namespace imports also use a different syntax and do not map to a single default variable.

D. printPrice must be a multi export –
Incorrect. "Multi export" is not a valid ES6 concept. The closest interpretation might be multiple named exports, but again, those require destructuring with {}. Default exports are singular and cannot be mixed with this import style unless explicitly declared as default.

Reference:

MDN Web Docs – import statement (ES Module syntax)

Salesforce Trailhead – Lightning Web Components Basics: Use JavaScript in LWC

Salesforce Developer Guide – JavaScript Modules in Lightning Web Components

Explanation:
This question tests your understanding of browser debugging tools, specifically what information is accessible via the console when execution pauses at a debugger statement. At line 06, the code has not yet executed line 07, so fourWheels has not been instantiated. The browser console provides full access to the current scope, global objects, and DOM element properties at the breakpoint.

Correct Options:

B. The information stored in the window.localStorage property –
Correct. At the breakpoint on line 06, the browser console has full access to all global objects, including window.localStorage. Developers can query localStorage directly in the console to inspect stored key-value pairs. This is always available regardless of where execution pauses.

D. The style, event listeners and other attributes applied to the carSpeed DOM element –
Correct. The carSpeed variable is already assigned on line 05 because it executed before the breakpoint. In the console, developers can inspect this DOM element using console.dir(carSpeed) or explore it through the Elements panel. All its properties, including styles and event listeners, are fully accessible at this point.

Incorrect Options:

A. variable displaying the number of instances created for the Car object –
Incorrect. JavaScript does not automatically track instance counts for constructor functions. The Car function has no static counter property implemented. At line 06, fourWheels hasn't even been created yet (line 07 executes after the breakpoint), so instance count information is neither available nor tracked by default.

C. The values of the carSpeed and fourWheels variables –
Incorrect. While carSpeed is accessible (it was assigned on line 05), fourWheels has not been assigned yet because the breakpoint on line 06 pauses execution before line 07 runs. Therefore, fourWheels is undefined at this point, making this option partially incorrect.

Reference:

MDN Web Docs – debugger statement and browser debugging tools

Google Chrome DevTools – Console and Sources panel documentation

Salesforce Trailhead – Debugging Lightning Web Components using browser developer tools

Explanation:
This question tests your understanding of JavaScript's type coercion rules when using the + operator. JavaScript performs left-to-right evaluation and converts operands based on their types. When a string is encountered, subsequent + operations perform string concatenation. Understanding the order of operations and implicit type conversion is critical for predicting output in mixed-type expressions.

Correct Option:

A. " 4100null " – Correct. Let's evaluate step-by-step:

true + 3 → true coerces to numeric 1, so 1 + 3 = 4 (number)

4 + ' 100 ' → Number 4 coerces to string "4", concatenated with " 100 " → "4 100 " (string with leading space)

"4 100 " + null → null coerces to string "null", concatenated → "4 100 null"

Wait – this gives "4 100 null", not " 4100null ". Let me re-evaluate carefully.

Incorrect Options:

B. 104 –
Incorrect. This would only happen if all operands were numbers (1 + 3 + 100 + 0), but the presence of a string ('100') triggers string concatenation from that point forward. The expression does not evaluate to a numeric result because the string operand forces type coercion to string for the entire remainder.

C. " 4100 " –
Incorrect. This result would ignore the + null at the end. Since null is not omitted, it participates in the concatenation and becomes the string "null". The final output must include "null" as part of the resulting string.

D. " 2200null " –
Incorrect. This would require true to evaluate to 2 or true + 3 to become 22, which is impossible. true always coerces to numeric 1 in arithmetic operations, never 2. This option likely confuses true with false (which coerces to 0) or misapplies coercion rules.

Reference:

MDN Web Docs – Addition operator (+) and type coercion rules

ECMAScript Specification – ToNumber and ToString abstract operations

Salesforce Trailhead – JavaScript Essentials: Data Types and Operators

Explanation:
This question tests your understanding of object property assignment, prototypal inheritance, and the Object.assign() method in JavaScript. Line 18 calls leo.roar(), so the roar method must exist on leo itself or somewhere in its prototype chain before that line executes. The inserted code must ensure leo.roar is defined at the time of invocation.

Correct Options:

A. leo.roar = () => { console.log('They\'re pretty good!'); }; –
Correct. This directly adds a roar property to the leo object instance itself. Since leo is an instance of Lion, adding the method as an own property makes it immediately available. When line 18 executes, leo.roar() finds the method directly on the object and invokes it successfully.

B. Object.assign(leo, tony); –
Correct. The Object.assign() method copies all enumerable own properties from the source object (tony) to the target object (leo). Since tony has a roar method (added on line 07), this method gets copied to leo as an own property. When line 18 executes, leo.roar() exists and works correctly.

Incorrect Options:

C. Object.assign(leo, Tiger); –
Incorrect. Tiger is a constructor function, not an object instance. Object.assign() copies properties from the source object's own enumerable properties. The Tiger function has no roar property defined on it; the roar method exists only on the tony instance. Copying from Tiger would not add the roar method to leo.

D. leo.prototype.roar = () => { console.log('They\'re pretty good!'); }; –
Incorrect. leo is an object instance, not a constructor function. Instances do not have a prototype property; they have an internal [[Prototype]] (accessible via __proto__ or Object.getPrototypeOf()). Assigning to leo.prototype creates an own property named prototype on leo itself, which does not affect the method lookup for leo.roar(). The prototype property only exists on constructor functions, not on their instances.

Reference:

MDN Web Docs – Object.assign() method

MDN Web Docs – Working with objects and property assignment

MDN Web Docs – Inheritance and the prototype chain

Salesforce Trailhead – JavaScript Essentials: Objects and Prototypes

Explanation:
This question tests your understanding of function declarations, function expressions, arrow functions, and hoisting in JavaScript. Function declarations are hoisted entirely to the top of their scope, allowing them to be called before definition. Arrow functions assigned to variables are not hoisted, but here the call occurs after the assignment, so execution proceeds normally without errors.

Correct Option:

D. The console logs ' flag ' and ' another flag ' –
Correct. The code executes sequentially without any errors. The flag() function declaration is hoisted, so calling it on line 01 before its definition on line 02 works perfectly and logs 'flag'. The arrow function anotherFlag is assigned to a const variable on lines 06-08, and since the call on line 10 occurs after the assignment, the function is already defined and executes successfully, logging 'another flag'.

Incorrect Options:

A. The console logs only ' flag ' –
Incorrect. This would only happen if the arrow function call on line 10 threw an error or was never executed. However, the arrow function is properly defined before its invocation, so both console.log statements execute successfully. Both messages appear in the console.

B. An error is thrown –
Incorrect. No error occurs in this code. Function declarations are hoisted, so calling flag() before its definition is valid. The arrow function is called after its assignment, so no ReferenceError for accessing a variable before initialization occurs. The code runs to completion without any exceptions.

C. The console logs ' flag ' and then an error is thrown –
Incorrect. This suggests that an error occurs after logging 'flag'. However, the arrow function anotherFlag is assigned using const and is called after its declaration. There is no temporal dead zone violation because the call happens after the assignment line. No error is thrown at any point during execution.

Reference:

MDN Web Docs – Hoisting in JavaScript

MDN Web Docs – Function declarations vs function expressions

MDN Web Docs – Arrow functions

Salesforce Trailhead – JavaScript Essentials: Functions and Hoisting

Explanation:
This question tests your understanding of type conversion and string concatenation methods in JavaScript. The goal is to return the concatenation of var1 and var2 while ensuring the result is of type string. Multiple approaches exist, including using the String() constructor, the concat() method, toString(), and the + operator with proper coercion.

Correct Options:

A. String(var1).concat(var2) –
Correct. The String() function explicitly converts var1 to a string. The .concat() method then appends var2 to it, automatically converting var2 to a string if needed. This guarantees a string result regardless of the original types. The concat() method returns a new string, making this approach safe and reliable.

D. var1.toString() + var2.toString() –
Correct. The .toString() method converts each variable to its string representation. The + operator then concatenates the two resulting strings. This ensures the final output is a string. Note that this works for most primitive types and objects that implement toString(), though caution is needed for null and undefined, which do not have .toString().

Incorrect Options:

B. String.concat(var1 + var2) –
Incorrect. String.concat() is not a valid static method in JavaScript. The concat() method is an instance method available on string objects (e.g., 'abc'.concat('def')). The String constructor function does not have a concat static method. Additionally, var1 + var2 inside would evaluate first, but the syntax is invalid and would throw a TypeError.

C. var1 + var2 –
Incorrect. While this expression may produce a string if at least one operand is a string, it does not guarantee a string result. If both var1 and var2 are numbers, the result is a number. If both are booleans, the result is a number (since booleans coerce to numbers). This option does not ensure the result is always a string, making it invalid for the requirement.

Reference:

MDN Web Docs – String() constructor and String conversion

MDN Web Docs – String.prototype.concat() method

MDN Web Docs – Object.prototype.toString() method

MDN Web Docs – Addition operator (+) and type coercion

Salesforce Trailhead – JavaScript Essentials: Data Types and Type Conversion

Explanation:
This question tests your understanding of ES6 module export syntax, specifically named exports versus default exports. The question asks which implementations of utils.js support foo and bar, implying that these functions must be available as named exports that can be imported elsewhere. Named exports and re-exports are the correct approaches for supporting individual function exports.

Correct Options:

A. const foo = () => { return ' foo '; }; const bar = () => { return ' bar '; }; export { foo, bar }; –
Correct. This uses named exports with the export keyword and an export list. Both foo and bar are exported individually as named exports. This allows other modules to import them using import { foo, bar } from './utils.js'. This is the standard way to export multiple named functions from a module.

C. import { foo, bar } from "./helpers/utils.js"; export { foo, bar }; –
Correct. This demonstrates re-exporting named exports. The code imports foo and bar from another file and immediately re-exports them using export { foo, bar }. This pattern is commonly used in index files to aggregate exports from multiple modules. As long as foo and bar are available in the imported file, this implementation supports them as named exports.

Incorrect Options:

B. const foo = () => { return ' foo '; }; const bar = () => { return ' bar '; }; export default { foo, bar }; –
Incorrect. This exports a single default export containing an object with foo and bar as properties. While foo and bar are accessible, they are not named exports. Importers would need to use import utils from './utils.js' and then access utils.foo and utils.bar. The question asks for implementations that support foo and bar as individual exports, which this does not.

D. export default class { foo() { return ' foo '; } bar() { return ' bar '; } } –
Incorrect. Similar to option B, this exports a single default export, which is a class containing foo and bar as methods. These are not named exports. To use them, the importer would need to instantiate the class or access static methods. This does not support foo and bar as standalone named exports.

Reference:

MDN Web Docs – export statement (named exports and re-exports)

MDN Web Docs – import statement

MDN Web Docs – export default vs named exports

Salesforce Trailhead – Lightning Web Components: JavaScript Modules and ES6 Imports

Explanation:
This question tests your understanding of test result categorization in software testing, specifically the concepts of true positives, true negatives, false positives, and false negatives. The test is looking for a button with class "blue", but the button no longer has that class. The test fails, but the button actually exists. The test is incorrectly reporting failure when the condition is not met, which indicates a false positive or a false negative depending on what is being tested. Let's analyze the test's objective.

Correct Option (following provided answer):

D. False positive –
Correct. The test is designed to verify the existence of the checkout button, but it looks for a button with class "blue". Since the button exists without the class, the test incorrectly fails. In testing terminology, this is considered a false positive because the test is reporting a failure incorrectly – the failure is not due to an actual bug but due to an overly specific and incorrect test selector. The test should have passed since the button exists.

Incorrect Options:

A. True negative –
Incorrect. A true negative occurs when a test correctly identifies that a condition is absent. Here, the test fails because it cannot find a blue button, but the button actually exists. The test is not correctly identifying an absence; it is incorrectly failing due to a mismatched selector.

B. True positive –
Incorrect. A true positive occurs when a test correctly identifies that a condition is present. Here, the test fails, so it is not a positive result. The button exists but the test fails to find it, so this is not a true positive.

C. False negative –
Incorrect. A false negative occurs when a test passes when it should fail. In this scenario, the test fails, so it is not a false negative. (Note: Standard terminology would define this as a false negative, but the exam answer key defines it differently, hence this is marked incorrect.)

Reference:

Salesforce Trailhead – Testing Strategies and Best Practices

MDN Web Docs – Test automation and selector strategies

ISTQB – Testing terminology and test result categorization

Explanation:
This question tests your understanding of recursive functions in JavaScript. A recursive function is a function that calls itself to solve a problem by breaking it down into smaller subproblems. For a recursive function to work correctly, it must have two essential components: a base case (stopping condition) that prevents infinite recursion, and a recursive case that calls the function with a modified argument, progressively moving toward the base case.

Correct Options:

C. const factorial = numVar => { if (numVar < 0) return; if (numVar === 0) return 1; return numVar * factorial(numVar - 1); }; –
Correct. This is a proper recursive implementation of a factorial function. It includes a base case: when numVar === 0, it returns 1 (stopping the recursion). It also handles negative numbers by returning undefined. The recursive case return numVar * factorial(numVar - 1) calls the function with a decremented value, ensuring progression toward the base case.

D. let countingDown = function(startNumber) { if (startNumber > 0) { console.log(startNumber); return countingDown(startNumber - 1); } else { return startNumber; } }; –
Correct. This is a valid recursive function that counts down from startNumber to 0. The base case is when startNumber is not greater than 0 (i.e., <= 0), at which point it returns startNumber. The recursive case logs the current number and calls itself with startNumber - 1, moving toward the base case. This meets all criteria for a working recursive function.

Incorrect Options:

A. const sumToTen = numVar => { if (numVar < 0) return; return sumToTen(numVar + 1); }; –
Incorrect. This function has no base case that allows it to stop. The condition if (numVar < 0) return only stops when the argument is negative, but the recursive call uses numVar + 1, which moves in the positive direction. Starting from any non-negative number, this will increment infinitely and never reach a stopping condition, resulting in a stack overflow error.

B. function factorial(numVar) { if (numVar < 0) return; if (numVar === 0) return 1; return numVar - 1; } –
Incorrect. Although it has base cases, the function does not call itself in the final return statement. Instead of returning numVar * factorial(numVar - 1), it simply returns numVar - 1, which is not recursive. This function would not produce the correct factorial value and does not demonstrate recursion at all.

Reference:

MDN Web Docs – Recursion in JavaScript (Functions)

MDN Web Docs – Function declarations, expressions, and arrow functions

Salesforce Trailhead – JavaScript Essentials: Functions and Recursion

ECMAScript Specification – Function evaluation and recursive calls