Static Testing

Static testing is a type of software testing in which the software application is examined without executing the code. During this process, requirement documents, design documents, and the source code are checked to find defects. The main goal of static testing is to improve software quality by detecting errors early in the development lifecycle. Static testing can identify errors that dynamic testing cannot, but the reverse is also true: dynamic testing can also detect issues that fall outside the scope of static testing. In a testing project, both methods are necessary.

Loading the example project:

• Extract the workspace.zip file
• Start IntelliJ
• File -> New -> Project From Existing Sources... then locate the .project file inside the workspace folder and select it.

Opening the project in Eclipse

The provided file contains an Eclipse project. To open it in the original environment:

• Start Eclipse
• File -> Import ... -> General -> Existing project into workspace

Projects in IntelliJ

IntelliJ is capable of opening and managing various project types. Eclipse projects are usually provided as .project or .classpath files. For Maven projects, the pom.xml file acts as the project descriptor. For Gradle projects, this is the *.gradle file.

Code Review

Code review is the manual analysis of the code. When performing a review, all changes made to the code must be examined before the new implementation is merged into the codebase. During the review, we look for defects (functional issues, typos, misplaced code fragments) and document them.

In general, reviewing production code is not the primary responsibility of testers. Their focus should remain on validating functionality, automation logic, and test coverage. If an automated test framework is in place, it is typically the tester’s role to review the test code itself—ensuring its correctness, maintainability, and reliability—rather than performing reviews on core application logic.

In modern development workflows, static analysis tools are commonly integrated into the CI pipeline. These tools act as a form of quality gate, automatically checking for style violations, security issues, code smells, and other problems before code can be merged. This helps ensure that basic quality standards are enforced without relying solely on manual reviews.

There are a few basic rules to follow during a code review:

• Clarify and define the goals of the review!
• Understand the code!
• Build and test the code before the review!
• Spend no more than 1 hour on the review!
• Do not review more than 500 lines!
• Provide constructive criticism and avoid personal remarks!
• Use checklists!

The most important aspects to consider during a code review are: structure, style, logic, performance, readability, and functionality.

Questions we may ask:

• Do I understand what the code does?
• Does the code work the way it should — meaning according to the functional specification?
• Does the code comply with the company’s coding style?

Static Analysis

Static code analysis aims to determine what potential bugs or vulnerabilities are present in the provided source code. This is decided solely based on the content and structure of the code — the code is not executed, only analyzed at compile-time.

Preparations

Install the following analyzers in IntelliJ:

• SpotBugs installation:
• Open: JetBrains Marketplace SpotBugs and click GET.
• Select your IntelliJ version (community, ultimate).
• Choose a plugin version and click the download link.
• In IntelliJ, open the settings menu (CTRL-ALT-S).
• Click the Plugins menu.
• Click the gear icon and select Install plugin from disk.
• Locate the downloaded plugin (e.g.,: spotbugs-idea-1.2.5.zip) and install it.

• Restart IntelliJ.

  

• PMD installation:

• Link: PMD plugin
• Open the link and click GET.
• Select the IntelliJ version (community, ultimate).
• Choose a plugin version and click the download link.
• Choose a plugin version and click the download link.
• Navigate to Plugins.
• Using the gear icon, choose Install plugin from disk.
• Install the downloaded plugin (e.g.,: PMDPlugin-1.8.26.zip).

• Restart IntelliJ.

• Checkstyle installation:

• Link: Checkstyle IntelliJ Plugin
• Open the link and click GET.
• Select the IntelliJ version (community, ultimate).
• Choose a plugin version and download it.
• Open IntelliJ settings (CTRL-ALT-S).
• Go to Plugins.
• Use the gear icon to select Install plugin from disk.
• Install the downloaded plugin (e.g., CheckStyle-IDEA-5.83.0.zip).
• Restart IntelliJ.

Installing static analyzers in Eclipse

In Eclipse, installation works as follows:

• SpotBugs
• Help -> Eclipse Marketplace
• Search: spotbugs; install SpotBugs Eclipse plugin 3.1.5
• PMD
• Help -> Eclipse Marketplace
• Search: checkstyle; install pmd-eclipse-plugin 4.28.0
• Checkstyle
• Help -> Eclipse Marketplace
• Search: pmd; install Checkstyle Plug-in 8.44.0

Differences from the installation steps

There may be differences between Eclipse and IntelliJ versions compared to the process described above!

Pre-commit hook

Tools like Checkstyle can support consistent code quality by automatically enforcing the project’s coding standards. Checkstyle can also be integrated as a Git pre-commit hook, preventing developers from committing code that violates the defined style rules. This ensures that many formatting and structural issues are caught early—before the code even reaches the review or CI stages.

Using the Static Analyzers

All analyzers can be launched from the project context menu (right-click on the project):

• SpotBugs -> SpotBugs
• CheckStyle -> Check Current File
• PMD -> PMD

Results appear both in code and in a separate tool window. If that window does not open automatically, you can enable it via: Window -> Show View -> Other ...

Static analyzer reports may be huge!

Pay attention to how the tools are configured. These tools can report a very large number of issues, which may become counterproductive. (A developer may gladly examine 10 issues, but if we present 10,000 at once, they will not even start.) Configure the system to show only the most important issues!!

Which issues are considered important?

The answer depends on the individual/organization/context. Warnings pointing to concrete bugs or potential failures are usually considered more important, while cosmetic issues are less critical. However, in the long term, poorly formatted code can also result in high costs, so such findings can also be significant. A statikus elemzők konfigurációi az alábbi módon érhetők el az IntelliJ IDEA keretrendszerben:

• CheckStyle
• File -> Settings
• Select the configuration file (two defaults are included, but any custom config file may be added).

Configuration files

Configuration files are XML-based and can be freely edited or extended. See: CheckStyle configuration

• SpotBugs

• File -> Settings

• PMD

• File -> Settings

Configuration settings in Eclipse

In Eclipse, settings can be modified as follows:

• SpotBugs
• Projekt kontext menü -> Properties -> SpotBugs
• Configure Workspace Settings
• CheckStyle
• Window menü -> Preferences -> CheckStyle
• New or Copy -> Configure...
• PMD
• Window menü -> Preferences -> PMD -> Rule Configuration

Tools for other languages

C/C++ Cppcheck

Cppcheck is one of the most widely used static code analyzers for C and C++. Its main advantage is that it is not a compiler, meaning it can detect issues that compilers often miss.

What does it analyze?

• memory leaks
• dereferencing null pointers
• out-of-bounds access
• resource-management issues
• uninitialized variables
• unnecessary or incorrect logic
• dangerous implicit conversions
• C++-specific issues (RAII misuse, STL misuse, etc.)

Advantages:

• igh accuracy with few false positives
• easy to integrate into CI pipelines
• available both as CLI and GUI
• supports MISRA rulesets

MISRA

MISRA provides best practice guidelines for the safe and secure application of both embedded control systems and standalone software.

Executon:

cppcheck --enable=all src/

C/C++ Valgrind - not a static analysis tool!

Valgrind is a powerful dynamic analysis framework widely used in C and C++ development to detect memory-related errors and performance issues. While Cppcheck performs static analysis, Valgrind analyzes the program while it runs, making it indispensable for uncovering runtime memory problems. Although not a “static analyzer” in the strict sense, it is one of the most important tools for memory correctness — and often taught alongside static analysis.

What does Valgrind do?

Valgrind provides several analysis tools, the most important being Memcheck, which detects:

1. Memory errors

2. Invalid reads and writes (accessing memory you don’t own)

3. Use of uninitialized memory
4. Reading/writing freed memory
5. Overrunning buffers

6. Stack and global memory misuse

7. Memory leaks

8. Definitely lost memory (true leaks)

9. Indirectly lost memory
10. Possibly lost memory

11. Reachable but never freed memory

12. Incorrect heap usage

13. Double free

14. Mismatched malloc/free or new/delete
15. Incorrect realloc usage

Python - Pylint

Pylint is one of the most comprehensive and strict static analyzers and linters in the Python ecosystem.

What does it analyze?

• typical errors: missing attributes, wrong module references, typos
• variable and function type issues
• unused variables and unused imports
• code complexity (cyclomatic complexity)
• PEP8 style guide violations
• import order issues
• missing documentation and naming convention problems

Advantages:

• detailed, structured reports
• gives each module a score (0–10)
• highly configurable
• extensible with custom rules

Example execution:

pylint mymodule.py

JavaScript / TypeScript — ESLint

ESLint is the standard static analyzer and linter for JavaScript and TypeScript.

What does it analyze?

• JavaScript syntax errors
• unused variables and unused imports
• dangerous comparisons (== instead of ===)
• async/await misuse
• promise handling issues
• TypeScript type errors (when used with TSESLint + TypeScript compiler)
• code style and best practices

Advantages:

• extremely extensible (hundreds of plugins)
• strong TypeScript support (@typescript-eslint/*)
• widely used rule presets (Airbnb, Google, etc.)
• automatic fixing with --fix

Example execution:

npx eslint src --ext .js,.ts

SonarQube

SonarQube is a widely used, enterprise-grade static analysis and code quality platform that supports more than 25 programming languages, including:

• Java, Kotlin
• Python
• C/C++
• JavaScript / TypeScript
• Go, PHP, C#, Ruby, Scala
• …and many others.

It is typically deployed as a server application that continuously analyzes source code from Git repositories or CI pipelines, providing dashboards, reports, and quality metrics.

What does SonarQube analyze?

SonarQube focuses on three core areas:

1. Bugs

   • null pointer dereferences
   • logic errors
   • incorrect conditions
   • boundary errors

2. Vulnerabilities

   • SQL injection
   • XSS
   • insecure deserialization
   • use of deprecated or unsafe APIs

3. Code Smells

   • duplicated code
   • overly complex methods
   • long parameter lists
   • poor naming conventions
   • unused code

A core SonarQube feature is the Quality Gate, which is a set of conditions that must be met before code can be merged.

Metrics and Dashboards:

SonarQube gives visual dashboards:

• Maintainability rating (A–E)
• Security rating
• Reliability rating
• Code duplication percentage
• Cyclomatic complexity
• Coverage (from unit tests)
• Technical debt estimation (minutes/hours)

This makes it a preferred tool in organizations that enforce code quality standards.

How does SonarQube work?

1. SonarQube Server

2. Runs the UI, dashboards, database, rule sets.

3. Sonar Scanner

4. Runs the analysis (via CI or locally):

   sonar-scanner
   

5. Plugins and Rules

   SonarQube supports:

6. built-in rules for each language

7. community plugins
8. custom rules with XPath, Java, or JavaScript

OpenStaticAnalyser (OSA)

OpenStaticAnalyzer is an open-source, multi-language static code analysis platform created to detect coding issues, security vulnerabilities, and maintainability problems across various programming languages.

OpenStaticAnalyzer provides deep static analysis of source code. Using the results of the analysis, the quality of the analyzed source code can be improved and developed both in the short- and long term in a directed way.

Product characteristics:

• Platform-independent command line tools
• Transparent integration into build processes
• Powerful filter management
• Coding issue detection:
  • Metric threshold violations (MetricHunter module)
  • Common programming mistakes (clang-tidy)
  • Cppcheck 2.5 coding rule violation
  • Re-prioritized and carefully selected PMD 6.32.0 coding rule violations
  • SpotBugs 4.2.2 coding rule violations
  • Pylint 1.9.4 and 2.3.1 coding rule violations
  • FxCop coding rule violations
  • Roslyn Analyzer coding rule violations
  • ESLint coding rule violations
  • SONARQUBE™ platform 8.0 coding rule violations
• Clone detection (copy-pasted source code fragments) extended with clone tracking and "clone smells"
  • Syntax-based, so-called Type-2 clones
• Metrics calculation at component, file, package, class, method, and function levels:
  • Source code metrics
  • Clone metrics
  • Coding rule violation metrics Supported languages: Java, Python, C#, JavaScript, C/C++.

OSA has a commercial version called SourceMeter.

.NET tools

• FxCop is a free static code analysis tool from Microsoft that checks .NET managed code assemblies for conformance to Microsoft's .NET Framework Design Guidelines.
• Roslyn Analyzers are tools built on the .NET Compiler Platform (Roslyn) that analyze C# or Visual Basic code to ensure style, quality, maintainability, and adherence to design principles. These analyzers operate during design time, providing real-time feedback in the code editor and error list.

Homework: Examining the Calculator

Examine the code in the Calculator package inside the workspace.zip!

Run the static analyzers (at least SpotBugs) on the project! Look through the reported issues — search for several ones and minor ones.

• What issues were found by the analyzers?
• Are all issues found by the tools real issues?
  • (Note: not all issues reported by static analysis tools are actual problems; local project settings and frameworks may influence the results.)
• What happens if you reduce the minimum rank in SpotBugs from 20 to 15?

---

Utolsó frissítés: 2025-11-16 13:00:47