SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • ShellShell
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
Apex

Apex static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your APEX code

  • All rules 97
  • Vulnerability2
  • Bug26
  • Security Hotspot3
  • Code Smell66
Filtered: 5 rules found
testing
    Impact
      Clean code attribute
        1. Arguments to "assertEquals" and "assertNotEquals" should be in the correct order

           Code Smell
        2. SOSL queries in test methods should use "Test.setFixedSearchResults"

           Code Smell
        3. Test classes and methods should not use "seeAllData=true"

           Code Smell
        4. Private members made public for testing should use "@TestVisible" annotation

           Code Smell
        5. Test methods should include meaningful assertions

           Code Smell

        SOSL queries in test methods should use "Test.setFixedSearchResults"

        intentionality - complete
        reliability
        Code Smell
        • salesforce
        • apex
        • testing
        • sosl

        This rule raises an issue when an SOSL query is used in a test method without calling Test.setFixedSearchResults() beforehand.

        Why is this an issue?

        How can I fix it?

        More Info

        SOSL (Salesforce Object Search Language) queries behave differently in test contexts compared to production environments. By default, any SOSL search executed within a test method returns empty results, regardless of the data that exists in the test database.

        This behavior can lead to several problems:

        • Unpredictable test results: Tests may pass or fail inconsistently because they rely on empty search results rather than controlled test data.
        • False test outcomes: A test might pass when it should fail, or fail when it should pass, because the SOSL query doesn’t return the expected data.
        • Incomplete test coverage: The actual logic that processes SOSL results may not be properly tested if the queries always return empty results.

        To ensure reliable and predictable test behavior, Salesforce provides the Test.setFixedSearchResults() method. This method allows you to specify exactly which record IDs should be returned by SOSL queries during test execution, giving you full control over the test scenario.

        What is the potential impact?

        Tests that rely on SOSL queries without proper setup may produce unreliable results, leading to false confidence in code quality. This can result in bugs being deployed to production that could have been caught with properly configured tests.

          Available In:
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories

        © 2025 SonarSource Sàrl. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use