SWT301 LAB2 REPORT

HE172450 - ĐẶNG ĐÌNH VƯỢNG

I. Introduction Project and Testing Tool

1. Introduction Project
- Name: FPT_Cinema

- Purpose: Users can book movie tickets in cinema, choose type of seats or cancel
real-time tickets. System supports create online invoices and make payments

- User: Admin, movie ticket booker

+ Admin: Manage account login to the website, manage showings and movie
rooms in cinema

+ Movie Ticket Booker: View movie showtimes, view types of seats in movie
rooms, choose to book movie tickets and seat types, view realtime seat status.
Tickets create online invoices and make payments. Can view the history booked
tickets

2. Introduction to the Testing Tool:

2.1 Tool name: SonarLint

Description: SonarLint is a free IDE extension that empowers you to fix coding issues before they
exist. Moreover, SonarLint detects and highlights issues that can lead to bugs, vulnerabilities, and
code smells as you create your code. It offers clear remediation guidance and educational help, so
you can fix issues before the code is committed. SonarLint in VS Code supports analysis of JS/TS,
Python, PHP, Java, C, C++, C# and IaC code locally in your IDE.

2.2 Purpose of the Testing Tool:

Testing objectives:

● Code Quality Improvement: SonarLint aims to improve the overall quality of code by
identifying and suggesting fixes for coding standards violations, code smells, and
maintainability issues.

● Early Issue Detection: The tool helps in the early detection of bugs, security
vulnerabilities, and other code issues, preventing them from reaching later stages of the
development lifecycle.

● Consistent Coding Standards: SonarLint enforces coding standards and best practices,
ensuring that the codebase adheres to consistent guidelines.

2.3 Level of issue by Solarint

SonarLint, like many other static code analysis tools, categorizes the severity of issues based on their
potential impact on the application's security, performance, or maintainability. The severity levels are
usually classified as follows:

● Blocker: These issues indicate serious problems that can cause incorrect behavior of the
program, are susceptible to external attacks, or can lead to severe crashes in the product.
Examples include security vulnerabilities, issues causing application crashes.

● Critical: These are issues that usually encompass problems with a significant impact on
the application's performance or security, but not as severe as blocker issues. Examples
include memory leaks, the use of unsafe APIs.

● Major: These issues include problems that can significantly affect the maintainability of
the source code and can lead to logical or performance errors. Examples include violations of
best practices, non-compliance with coding standards.

● Minor: These issues usually involve smaller problems related to code quality that do not
seriously affect the functionality, performance, or security of the application. Examples
include unclean code writing, violations of coding style standards.
 ● Info: These are informational items about non-error issues that may require attention.
These are often suggestions for improving clarity, uniqueness, or performance of the code.

3. Test Strategy
3.1. Test approach

In the white-box testing approach for our project, we delve deeply into the internal structure and
design of the code to identify potential issues or defects. The focus will be on improving the quality
of the code by ensuring that it meets industry standards and best practices.

We use automated techniques to perform static analysis of the code. Automated techniques will
involve using tools like SonarLint to conduct unit tests and scan the code for potential issues related
to performance, and maintainability.

3.2. Test environment setup

To effectively implement SonarLint in our test environment, particularly within the Apache NetBeans
IDE 17, several critical steps and configurations are necessary. Here's a detailed setup plan:

Hardware and Software Configurations:

● Apache NetBeans IDE: Verify that all team members are using a compatible version of
Apache NetBeans, ideally the latest version to ensure full compatibility with SonarLint.
● SonarLint Plugin Installation:

Plugin Installation: Install the SonarLint plugin in Apache NetBeans. This can be done
through the IDE's plugin manager. Ensure that the installed version of SonarLint is
compatible with the version of NetBeans being used.

Configuration: Configure SonarLint settings in NetBeans to align with the project's

requirements. This includes setting up rules for code quality, security vulnerability
detection, and other relevant parameters.

● Project Configuration:

Dependencies and Libraries: Confirm that all necessary dependencies and libraries
required by the project are correctly configured and accessible in the NetBeans
environment.

4. Result achieved
4.1. Lines of Code (LOC) tested:

The tool successfully executed test cases on 6668 lines of code in 3 packages (controller, dal, model)
and 4 folders (Css, Javascript, Views, components) of the source package of our project.
4.2. Issue solutions:

Issue 1: S131 - “switch” statements should have “default” clauses

● Type: CODE_SMELL

● Cause: "switch" statements should have "default" clauses

● Level: CRITICAL

● Image before fix:

● Image after fixed:

● Lesson learned: A default case can serve as a catch-all for unexpected or erroneous
values, allowing the program to handle such situations gracefully

Issue 2: S2259 - Null pointers should not be dereferenced

● Type: BUG

● Cause: there's a risk of dereferencing a null pointer, which can lead to a

NullPointerException at runtime.

● Level: MAJOR
● Image before fix:

● Image after fixed:

● Lesson learned: By including these null checks, you prevent potential null pointer
dereferences and ensure that the code behaves correctly even when specialization or doctor
are null.

Issue 3: S1144 - Unused "private" methods should be removed

● Type: CODE_SMELL

● Cause: here are methods in a class that are declared as private but are not used
anywhere within the class.

● Level: MAJOR

● Image before fix:

● Image after fixed:

● Lesson learned: By removing the unused private method, you keep the class focused and
easier to understand for developers who work with it.

Issue 4: S1319 - Declarations should use Java collection interfaces such as "List"
rather than specific implementation classes

● Type: CODE_SMELL
● Cause: method signatures, variable declarations, and return types, it's preferable to use
interfaces

● Level: MINOR

● Image before fix:

● Image after fixed:

● Lesson learned: This allows you to pass any type of List implementation, such as
ArrayList, LinkedList, or any other class that implements the List interface, to
the method.

Issue 5: S125 - Sections of code should not be commented out

● Type: CODE_SMELL

● Cause: when sections of code are commented out and left in the source code

● Level: MAJOR

● Image before fix:

● Image after fixed:

● Lesson learned: Should not comment in sections of code

 Issue 6: S118 - Utility classes should not have public constructors

● Type: CODE_SMELL

● Cause: define a public constructor in a class that serves as a utility class

● Level: MAJOR

● Image before fix:

● Image after fixed:

● Lesson learned: This prevents instantiation of the class, reinforcing its purpose as a
utility c lass containing static methods or constants.

Issue 7: S2589 - Boolean expressions should not be gratuitous

● Type: CODE_SMELL

● Cause: boolean expressions are unnecessarily complex or convoluted, making the code
harder to read and understand

● Level: MAJOR

● Image before fix:

● Image after fixed:

● Lesson learned: This approach eliminates unnecessary nesting and makes the boolean
expression straightforward and easier to understand.
Issue 8: S2119 - "Random" objects should be reused

● Type: BUG

● Cause: multiple instances of the Random class are created unnecessarily

● Level: CRITICAL

● Image before fix:

● Image after fixed:

● Lesson learned: This ensures that the Random object is reused, addressing the advice to
avoid unnecessary instantiation of Random objects.

Issue 9: S1192 - String literals should not be duplicated

● Type: CODE_SMELL

● Cause: he same string literal is used multiple times within the codebase

● Level: CRITICAL
 ● Image before fix:

● Image after fixed:

● Lesson learned:By defining constants for the conversion types, you ensure that the string
l iterals are not duplicated and provide more meaningful names for the conversion options.

Issue 10: S1066 - Collapsible "if" statements should be merged

● Type: CODE_SMELL

● Cause: there are many redundant if statements

● Level: MAJOR

● Image before fix:

● Image after fixed:

● Lesson learned:This approach eliminates unnecessary nesting and makes the boolean
expression straightforward and easier to understand.
Issue 11: S2095 - Resources should be closed

● Type: CODE_SMELL

● Cause: occurs when resources such as streams, connections, or file handles are opened
but not explicitly closed after they are no longer needed

● Level: MAJOR

● Image before fix:

● Image after fixed:

● Lesson learned: With this change, the PreparedStatement and ResultSet will be
automatically closed when they are no longer needed, even if an exception occurs, ensuring
proper resource management and reducing the likelihood of resource leaks.

Issue 12: S4925 - "Class.forName()" should not load JDBC 4.0+ drivers

● Type: CODE_SMELL

● Cause: don't need to use Class.forName() to load the driver. Instead, you
can simply rely on the DriverManager class to automatically load the driver when
needed.

● Level: MAJOR

● Image before fix:

● Image after fixed:

● Lesson learned: With this change, you no longer need to explicitly load the driver class,
as it will be automatically loaded when needed. This simplifies the code and aligns it with
modern JDBC practices.

Issue 13: S108 - Nested blocks of code should not be left empty

● Type: CODE_SMELL

● Cause: occurs when a method is defined without any statements or meaningful code
inside its body.

● Level: MAJOR

● Image before fix:

● Image after fixed:

● Lesson learned:adding this logging statement, you provide a record of the exception
occurrence, which can be helpful for debugging and troubleshooting purposes

Issue 14: S1186 - Methods should not be empty

● Type: CODE_SMELL
● Cause: methods that don't contain any statements or logic

● Level: MAJOR

● Image before fix:

● Image after fixed:

● Lesson learned: You should put the logic to handle the request inside this
method.

Issue 15: S3010 - Static fields should not be updated in constructors

● Type: CODE_SMELL

● Cause: Initializing static fields inside constructors is generally discouraged because it

may lead to unintended consequences

● Level: MAJOR

● Image before fix:

● Image after fixed:

● Lesson learned:This way, the products list is initialized only once when the class is
loaded, and it cannot be modified thereafter.

Issue 16: S2209 - "static" members should be accessed statically

● Type: CODE_SMELL

● Cause: the products field is declared as static, but it's being accessed through an
instance (this.products) within the setProducts method

● Level: MAJOR

● Image before fix:

● Image after fixed:

● Lesson learned: By accessing the products list using the class name ListProduct,
you ensure that static members are accessed statically, as required by the error message.

Issue 17: S1854 - Unused assignments should be removed

● Type: CODE_SMELL

● Cause: In this specific case, the warning is raised because the variable list is assigned a
new value immediately after it's initialized with an empty ArrayList

● Level: MAJOR

● Image before fix:

● Image after fixed:

● Lesson learned:he assignment List<Product> list = new ArrayList<>(); is removed, and the
list variable is assigned the result of dao.searchByName("puma") directly.

Issue 18: S1172 - Unused method parameters should be removed

● Type: CODE_SMELL

● Cause: use a lot of variable

● Level: MAJOR

● Image before fix:

● Image after fixed:

● Lesson learned: Delete used variable

Issue 19: S5869 - Character classes in regular expressions should not contain the
same character twice

● Type: CODE_SMELL

● Cause: when there is a repetition of characters within a character class in a regular

expression.

● Level: MAJOR

● Image before fix:

● Image after fixed:

● Lesson learned: This regular expression [0-9.*-]* matches zero or more occurrences
of digits, dots, or hyphens without repetition within the character class.

Issue 20: S100 - Method names should comply with a naming convention

● Type: CODE_SMELL

● Cause: Shared naming conventions allow teams to collaborate efficiently. This rule
checks that all method names match a provided regular expression.

● Level: MINOR

● Image before fix:

● Image after fixed:

● Lesson learned: Should not set uppercase on the first letter of function name