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: 13 rules found
apex
    Impact
      Clean code attribute
        1. SOSL queries in test methods should use "Test.setFixedSearchResults"

           Code Smell
        2. DML operations in catch blocks can mask original exceptions

           Bug
        3. Future methods must be static and return void

           Bug
        4. Test classes should have only one @testSetup method

           Bug
        5. Test classes and methods should not use "seeAllData=true"

           Code Smell
        6. Classes implementing "Database.Batchable" should be declared as "global"

           Bug
        7. "getRoleAndSubordinates()" should be replaced with "getRoleAndSubordinatesInternal()"

           Code Smell
        8. Future methods making HTTP callouts should include "callout=true" parameter

           Bug
        9. Test classes should be annotated with "@isTest"

           Code Smell
        10. SOQL queries should include LIMIT clauses to prevent hitting governor limits

           Bug
        11. Private members made public for testing should use "@TestVisible" annotation

           Code Smell
        12. SOQL queries should be assigned to Lists to avoid QueryException

           Bug
        13. Test methods should not have parameters

           Bug

        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