Testing Debugging And Deployment practice questions

sf apex run test

Why it fails: Executing `sf apex run test` initiates the execution of Apex unit tests rather than tailing system logs, making it unsuitable for capturing real-time log output during manual debugging or application usage. This command is tempting because developers frequently use Salesforce CLI tools during local troubleshooting sessions, and it represents a primary mechanism for running automated test suites and retrieving test execution summaries from the command line. It would be the correct choice when a developer needs to validate code coverage or verify that a specific set of unit tests passes successfully within an org.

sf project deploy start

Why it fails: Pushing local source files and metadata changes directly to an active scratch org or sandbox is the primary function of this command, making it tempting for developers working entirely within a terminal-based IDE workflow. However, it fails in this scenario because it manages deployments rather than establishing a persistent, real-time subscriber connection to listen for and stream server-side execution logs. A developer would correctly execute this command when they need to synchronise newly written Apex classes or custom objects from their local machine to a Salesforce environment.

sf org display

Why it fails: This command simply outputs authentication and connection details for a target Salesforce organisation, such as the username, instance URL, and access token, making it tempting for a developer who needs to verify their current CLI login state before running terminal operations. However, it fails in this scenario because it interacts exclusively with connection metadata rather than establishing a live telemetry subscription. To stream debug logs in real time to a local environment, the developer must execute the `sf apex tail log` command instead.

@isTest(SeeAllData=true)

Why it fails: Relying on pre-existing records rather than generating data via test setup methods is tempting because it bypasses governor limits on record creation and avoids writing repetitive code. Using this approach would be appropriate when a test specifically requires access to legacy attachments or metadata configurations that cannot be instantiated programmatically. However, it fails in this scenario because it exposes unit tests to unpredictable modifications from the live database, violating isolation best practices and causing intermittent failures when dependent records are missing or altered by concurrent processes.

@TestVisible

Why it fails: Allows private methods, variables, and inner classes to be accessed by test classes, which makes it tempting when test methods need to verify internal state. It would be the correct choice when a unit test needs to assert the value of a private variable or execute a private helper method rather than when sharing bulk data setup logic across multiple methods.

@Future

Why it fails: Future runs methods asynchronously and cannot be used for test data setup to share state in tests.

@ReadOnly

Why it fails: @ReadOnly is used on web service methods or batch Apex to restrict DML operations and increase query limits.

@TestVisible

Why it fails: Applying this annotation merely grants test methods or test setup methods access to private, protected, or package-private members of another class, such as private variables or methods, without altering database visibility or record isolation. It is tempting because developers frequently need to inspect internal class state during assertions, making it the correct choice when unit tests must access non-public properties of production classes. However, it does not configure data isolation rules or grant the test method access to pre-existing organisation data.

@TestSetup

Why it fails: @TestSetup is used for creating common test data once for multiple test methods in a class, not for marking the test method itself.

Connected Apps in the production org

Why it fails: Establishing Connected Apps in the production organisation is designed to handle OAuth-based external client integrations and single sign-on authentication, rather than creating the administrative trust relationship required for a standard change set deployment. While developers frequently interact with Connected Apps when configuring API integrations or third-party tools like Salesforce CLI, they do not facilitate direct sandbox-to-production deployment pathways. Deployment connections are established via Deployment Settings in the target organisation, making Connected Apps irrelevant for authorising Outbound Change Sets.

Named Credentials in both orgs

Why it fails: Establishment of a connection via Named Credentials is incorrect because outbound change sets rely on pre-configured deployment connections managed natively within Salesforce Setup under Deployment Settings, rather than programmatic callout endpoints. This option is tempting because Named Credentials securely store URL endpoints and authentication parameters for external API callouts, and would be the correct choice when configuring Apex or Flow integrations to securely consume external web services from an org.

Remote Site Settings in the source org

Why it fails: Remote Site Settings are used to whitelist external URLs for outbound HTTP callouts originating from Apex, Aura components, or Visualforce, making them tempting if one confuses metadata deployment pathways with programmatic API integrations. However, they fail in this scenario because Outbound Change Sets rely on pre-configured Salesforce-managed deployment connections established via Deployment Settings in the target organisation, rather than endpoint-specific security rules configured in the source sandbox.

The Developer Console caches old test results automatically.

Why it fails: Test results displayed in the Developer Console are derived from fresh execution logs rather than persistent caching, meaning a failed assertion cannot stem from retained historic data. This choice appears plausible because developers frequently encounter stale compilation states or cached view states within the broader Salesforce user interface, making automatic browser caching seem like a logical explanation for erratic test behaviour. In reality, Salesforce executes tests dynamically on-demand, meaning inconsistent outcomes always originate from shared state pollution between methods rather than static output retention.

The test class lacks the @isTest annotation.

Why it fails: Omitting the `@isTest` annotation causes the entire class to compile as standard application code rather than test context, meaning it would fail to execute altogether rather than pass in isolation and fail collectively due to data pollution. This annotation is essential for designating a class as a unit test container, and it is tempting to suspect its absence when test execution behaves unexpectedly because developers use it to define test scope. However, unannotated classes simply cannot be run via the Developer Console test runner at all.

Governor limits are permanently exhausted for the entire session.

Why it fails: Governor limits reset with each individual test method execution, meaning they are never permanently exhausted across an entire testing session. This explanation would be plausible if Apex governor limits accumulated globally and persisted across every transactional boundary within a developer console session, which would cause subsequent tests to fail once the cumulative threshold was breached. However, the Salesforce runtime environment enforces limits strictly per transaction, resetting them completely between independent test methods regardless of whether they run collectively or in isolation.

Use Test.expectException() before calling the method.

Why it fails: Apex does not contain a `Test.expectException()` method, meaning attempting to invoke it will result in a compilation error. This option is tempting because developers often look for a built-in testing framework utility to handle expected errors declaratively, similar to annotations found in other programming languages such as JUnit's `@Test(expected = ...)` or test runner assertions. Instead of a non-existent test method, Apex requires developers to use a `try`/`catch` block coupled with `System.assert()` or the `try`/`System.assert(false)` pattern inside the test method to explicitly capture and verify custom exception types.

Check Limits.getScriptStatements() after the method call.

Why it fails: Checking `Limits.getScriptStatements()` measures CPU governor limits by tracking executed Apex statements, making it completely ineffective for verifying whether a specific custom exception class was instantiated and thrown. This approach appears superficially attractive because developers frequently use `Limits` methods to monitor resource consumption, and it would be the correct choice if the unit test needed to guarantee that a block of code stayed within designated execution statement thresholds. However, it provides zero visibility into runtime exception types or messages.

Use System.assert(false, e.getMessage()) inside the catch block.

Why it fails: Putting the assertion inside the catch block means it only executes when caught, which is backward for verifying an exception is thrown.

Developers cannot view debug logs inside the Salesforce Developer Console.

Why it fails: The Developer Console includes a dedicated Logs tab specifically designed for capturing, viewing, and inspecting debug logs in real time without needing to navigate away to the Salesforce Setup menu. This statement is tempting because developers frequently utilise external IDEs or log management tools for advanced analysis, and the Console is often mistaken for a basic code editor rather than a full diagnostic environment. It would be a correct choice if the question asserted that debug logs cannot be natively inspected within the Developer Console interface during active troubleshooting sessions.

Debug logs are stored indefinitely in production without automatic purging.

Why it fails: Debug logs have retention limits and are automatically purged after a certain time or count.

Permanent production status with unlimited user licenses.

Why it fails: Scratch orgs are disposable, time-limited environments with capped user licences, so permanent production status and unlimited licences are impossible. It is tempting because scratch orgs do resemble production configurations for testing, but that scenario would use a sandbox or Developer Edition org instead.

Directly modifying standard Salesforce platform source code.

Why it fails: Salesforce scratch orgs rely on metadata-driven development where standard platform source code is proprietary and immutable, preventing developers from directly altering internal system binaries or core product code. This option sounds plausible because standard objects and platform features are fully customisable through metadata extensions like fields, triggers, and Apex classes. Developers would modify application logic directly in legacy monolithic architectures or open-source software platforms where source code access is permitted, whereas the Salesforce metadata model restricts customisation strictly to configurable layers above the core platform base.

The test method executes in read-only mode.

Why it fails: Apex unit test methods execute within the transaction context in read-write mode by default to enable the insertion, update, and deletion of test records necessary for validating application logic. Developers often confuse this with read-only operations designed for Apex REST get methods or Visualforce getter methods, where transactions are restricted to querying data without performing DML statements. In those read-only contexts, attempting to modify state throws a runtime exception, making this execution mode unsuitable for standard unit tests that must manipulate data to assert outcomes.

The test class code coverage is exactly 75%.

Why it fails: 75% code coverage is passing for deployment; individual test methods don't have individual coverage failure thresholds.

The test method finishes executing with zero assertions.

Why it fails: While bad practice, a test method with no assertions will pass as long as no unhandled exceptions occur (though some linters flag it).

@future(isTest=true)

Why it fails: This is not a valid combination of annotations.

@testVisible

Why it fails: @testVisible allows test methods to access private or protected members of another class.

@isTest(seeAllData=true)

Why it fails: This allows access to organization data, which is an anti-pattern for unit testing.

sf project retrieve start --validate

Why it fails: The `sf project retrieve start` command fetches metadata components from a connected environment into a local Salesforce DX project, making it tempting because developers frequently need to pull components down from sandboxes before managing deployments. However, it fails in this scenario because it performs a retrieval operation rather than a deployment validation. It would be the correct choice if the developer needed to synchronise local project files with changes made directly within a remote sandbox organisation.

sf project deploy validate

Why it fails: The deploy validate command is deprecated or non-standard; validation is done via flags on the deploy start command.

sf org check deploy

Why it fails: The `sf org check deploy` command expects an existing asynchronous deployment ID to check the progress of a previously initiated deployment, meaning it cannot initiate a new validation of local metadata files against a target org. It is tempting because its name suggests a general validation check, and it would be the correct choice when you need to monitor or verify the status of a deployment that is already running in the background on the Salesforce org.

Database.setSessionUser()

Why it fails: This method does not exist in Salesforce Apex.

Test.startTest() with a user profile parameter

Why it fails: Test.startTest does not accept user profile parameters.

UserInfo.setUserId()

Why it fails: UserInfo methods are read-only and cannot change the user context.

System.runAs()

Why it fails: There is no System.runAs method; it is Test.runAs.

@RemoteAction

Why it fails: @RemoteAction is used for JavaScript remoting in Visualforce.

@AuraEnabled

Why it fails: @AuraEnabled exposes methods to Lightning components.

Apex classes deployed via change sets are automatically executed in production for code coverage validation upon upload.

Why it fails: Apex tests never execute automatically upon the mere upload of a change set; instead, test execution is triggered manually during the inbound deployment validation or completion phase in the target organisation. Developers often assume this automated behaviour because Salesforce does require a minimum of 75 percent code coverage, and test classes *would* automatically run upon deployment if migrating code directly from a local development environment to production using Salesforce CLI (`sfdx force:source:deploy` or modern SF CLI equivalents) with the `--runlocaltests` or default test level parameters enabled.

Change sets support full rollback of the entire deployment if any single component fails.

Why it fails: Change sets are not transactional; a failed deployment leaves successfully deployed components in place, and rollback must be performed manually or by redeploying prior versions. Full automatic rollback is tempting because deployment tools often offer it, but Salesforce change sets commit each component independently as it deploys.

Change sets automatically delete components from the target organization if they are removed from the source.

Why it fails: Unmanaged change sets lack a deletion propagation mechanism, meaning removing a component from a source organisation leaves the corresponding asset intact in the target environment, requiring manual deletion via the user interface. Administrators accustomed to continuous integration pipelines or automated source-driven deployment tools—which routinely prune obsolete metadata during branch synchronization—often mistakenly assume change sets similarly mirror complete repository states.

@testMethod.

Why it fails: While `@testMethod` does successfully execute Apex unit tests and is tempting because of its long-standing history in Salesforce development, it is superseded by the modern standard. This annotation is functionally deprecated for method-level definitions in favour of the `@isTest` annotation, which applies class-wide and method-level visibility while supporting advanced parameters like `isParallel=true` and `seeAllData=true`. Therefore, relying solely on `@testMethod` limits your ability to configure modern test execution behaviour and does not represent best practice for contemporary declarative or programmatic test frameworks.

@TestVisible.

Why it fails: Allows private or protected methods and variables from a production class to be accessed by unit tests, which is tempting because it relates to testing functionality. However, it fails this specific scenario because it merely adjusts visibility boundaries rather than designating a method as an executable test case. It would be the correct choice when a test method in a separate class needs to assert the internal state of private variables or invoke helper methods that should otherwise remain encapsulated from public consumption during normal execution.

@future.

Why it fails: Methods annotated with `@future` execute asynchronously in a separate process, which prevents them from returning results directly to the synchronous Apex test runner or supporting the test context required for execution. Developers often reach for this annotation when attempting to test asynchronous operations or simulate callouts within a transaction. It is the correct choice for executing methods in the background after the current transaction finishes, such as processing web service callouts or handling heavy operations outside the primary trigger thread.

Only the failing test class is ignored.

Why it fails: Salesforce deployments via the Metadata API enforce an all-or-nothing transactional model where a single test failure causes the entire deployment to roll back, meaning failing tests can never be selectively ignored. This behaviour mimics local development where developers often run specific subsets of tests to isolate issues, which makes it tempting to assume that the platform would similarly isolate failures during automated deployments. Running a targeted subset of tests *would* be the correct choice when executing local validation via the Salesforce CLI using the `sfdx force:apex:test:run` command, where you can explicitly specify individual test classes rather than subjecting the entire codebase to mandatory validation.

The deployment succeeds but flags a warning.

Why it fails: A failed test class during a Metadata API deployment halts the entire transaction and causes the complete deployment to roll back, preventing the deployment from succeeding with merely a warning. This behaviour mirrors the less stringent validation logic applied in some packaging or asynchronous environments where test failures generate notifications rather than blocking updates. Such a tolerant outcome would only occur if running tests were explicitly bypassed in specific non-production contexts using targeted API parameters rather than standard deployment validation rules.

The deployment continues but prevents Apex compilation.

Why it fails: Failing test classes cause the entire Metadata API deployment to roll back rather than allowing partial continuation, because Salesforce enforces a zero-failure policy for unit tests during production deployments to maintain code quality. This behaviour mimics developer debugging phases where compiling code without strict test validation is occasionally useful for isolating syntax errors before writing assertions. Consequently, bypassing test execution entirely is sometimes desired during rapid initial code scaffolding, which is why developers might mistakenly assume compilation issues alone would trigger a partial deployment continuation.

sfdx force:apex:test:run -c

Why it fails: Using -c runs all tests in the package.

sfdx force:apex:test:run -f

Why it fails: No -f flag exists for test classes.

sfdx force:apex:test:run -u

Why it fails: The `-u` parameter specifies the target username or alias for the scratch org or default org against which the command executes, rather than filtering or selecting specific Apex test classes to run. This option appears plausible because developers routinely use `-u` to establish the active Salesforce org context for CLI operations. However, to target specific tests for execution, developers must instead use flags such as `-n` for test class names or `-s` for test suites.

To increase the execution time allowed for tests.

Why it fails: Extending execution limits is not achieved by `Test.startTest()`, which is actually designed to reset governor limits by providing a fresh set of SOQL queries, CPU time, and DML limits specifically for the asynchronous execution block that follows. This option is tempting because developers frequently confuse performance thresholds with governor limit management. However, if you need to handle long-running operations or prevent timeout exceptions in standard synchronous execution, you would instead utilise asynchronous processing paradigms or batch apex chunks rather than relying on test context methods.

To save the test data to the database immediately.

Why it fails: Saving test data immediately within a test method is achieved using standard DML operations followed by an explicit `Database.insert` or database commit, rather than `Test.startTest()`. This option is tempting because developers frequently need to ensure prerequisite records exist before executing business logic. However, `Test.startTest()` does not persist data; its actual purpose is to reset governor limits and collect asynchronous execution blocks into the test queue to run synchronously when `Test.stopTest()` is subsequently called.

To bypass user permission checks.

Why it fails: Test.startTest() resets the governor limits and pauses synchronous execution to gather asynchronous jobs, rather than bypassing user permissions. Developers might mistakenly think it alters security contexts because it changes runtime execution behaviour, a feature that would only be valid if the objective were to evaluate permission enforcement or run blocks of code under elevated security profiles, though permission validation is instead handled natively via `System.runAs()` during unit testing.

Test.assert().

Why it fails: Method names such as `assert()` do not exist on the `Test` class in Apex, which makes this syntax invalid at compile time. Developers frequently guess this method name because `Test` is the standard utility class for execution contexts and data setup in unit tests, and writing assertions is a fundamental part of verifying test outcomes. To validate expected behaviours correctly, Apex developers must use the `System.assert()`, `System.assertEquals()`, or `System.assertNotEquals()` methods provided by the `System` class instead.

Test.verify().

Why it fails: *Test.verify()* fails because no such method exists within the Apex `Test` utility class, meaning code attempting to use it will simply fail to compile. Developers often guess this syntax because it resembles assertion methods found in testing frameworks of other programming languages, where a generic verify method checks mock behaviour or state. In Salesforce Apex, however, assertions are handled exclusively by the `System` class methods such as `System.assertEquals()` or `System.assert()`, rendering `Test.verify()` entirely invalid.

Assert.verify().

Why it fails: `Assert.verify()` fails here because `verify` is not a valid method on the Salesforce `Assert` class, which instead relies on methods such as `areEqual`, `isTrue`, and `isNotNull` to validate test outcomes. This option is tempting because developers frequently encounter verification terminology in mocking frameworks or alternative programming ecosystems where `verify` is standard for checking method execution. However, in native Apex unit testing, `Assert` methods are strictly designed for validating state and expected values rather than verifying mock behavior.

Database: INFO.

Why it fails: To measure the performance of a SOQL query and satisfy the requirement to evaluate database execution times, the Database category must be set to the INFO level. This specific configuration directs the debug log to capture detailed execution metrics, including the exact milliseconds taken by database operations and the number of rows retrieved, without generating the excessive volume associated with finer-grained logging levels like DEBUG or FINEST.

System: DEBUG.

Why it fails: Setting the debug log category to System and the level to DEBUG records general application execution events such as variable assignments and method entries, making it tempting for developers accustomed to basic troubleshooting and tracing standard Apex code logic. However, this configuration fails because it does not capture database performance metrics; to measure SOQL query execution times and examine database resource consumption, the Database log category must be set to INFO or higher.

Apex Code: INFO.

Why it fails: Setting the log category to Apex Code at the INFO level records execution flow and method entries within programmatic logic, making it tempting because developers frequently associate performance profiling with code execution. However, this level fails to capture database query optimisation metrics because detailed SOQL execution plans, row counts, and query performance timings require the Database log category set to FINE or DEBUG.