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

        Test classes and methods should not use "seeAllData=true"

        consistency - conventional
        reliability
        Code Smell
        • salesforce
        • apex
        • testing

        This rule raises an issue when @isTest annotations use seeAllData=true at the class or method level.

        Why is this an issue?

        How can I fix it?

        More Info

        Using seeAllData=true in test classes or methods creates dependencies on existing data in the Salesforce org, which violates the fundamental principle of test isolation.

        When tests rely on existing org data, they become unreliable and unpredictable. The same test might pass in one environment but fail in another, simply because the required data exists in one org but not the other. Even worse, tests that have been working for months can suddenly start failing when someone deletes or modifies the records they depend on.

        Test isolation ensures that each test is self-contained and creates its own mock data. This approach guarantees that tests will behave consistently across different environments - development, staging, and production orgs.

        Additionally, there’s a technical restriction in Apex: seeAllData=true cannot be used when @testSetup methods are present in the same test class. This combination will cause a compilation error, preventing the code from being deployed.

        What is the potential impact?

        Tests become unreliable and may fail unexpectedly when dependent org data is modified or deleted. This can block deployments and create maintenance overhead. Tests may also behave differently across environments, making it difficult to ensure consistent application behavior.

          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