UNIT-II (10 Periods)

Source Code Management (GIT): The need for source code control, The history of source
code management, Roles and code, source code management system and migrations.
Version Control and GIT, GIT Installation, GIT features, GIT workflow, working with
remote repository, GIT commands, GIT branching, GIT staging and collaboration. UNIT
TESTING - CODE COVERAGE: Junit, nUnit & Code Coverage with Sonar Qube,
SonarQube - Code Quality Analysis.

Source Code Management (GIT): A Complete Guide

Source Code Management (SCM), also known as Version Control, is a critical practice in
modern software development. It enables teams to track and manage changes to source code
over time, facilitating collaboration and preventing conflicts. Git is the most widely used SCM
tool today.

1. The Need for Source Code Control

Without a version control system, managing code changes on a team can be chaotic and
error-prone. The need for SCM arises from several common challenges:

 Overwriting Changes: Multiple developers working on the same files can accidentally
overwrite each other's work.

 Reverting Errors: If a bug is introduced, it's difficult to identify which change caused
it and roll back to a working version.

 Lack of History: Without a history, it's impossible to know who made a change, when
they made it, and why.

 Inefficient Collaboration: Sharing code and merging changes becomes a manual,

tedious process.

The Need for Source Code Control (SCM)

Source Code Management (SCM), also known as Version Control, is a critical practice in
software development that addresses common challenges that arise when teams collaborate
on code. Without it, the development process can become chaotic, error-prone, and
inefficient.

Here are the key reasons why a version control system is essential:

1. Preventing Overwriting Changes

 The Problem: In a collaborative environment without SCM, multiple developers

working on the same files can save their changes, inadvertently overwriting the work
of their colleagues. This leads to lost code, wasted time, and significant frustration.

 The SCM Solution: A version control system provides a central repository where all
changes are managed. It uses a "merge" process to intelligently combine changes from
different developers, flagging any conflicts that need to be resolved manually. This
ensures that no one's work is lost.

2. Reverting Errors

 The Problem: Bugs and errors are an inevitable part of software development.
Without SCM, if a change introduces a critical bug, it's extremely difficult to undo that
specific change without affecting other parts of the code. This can turn debugging into
a manual, time-consuming effort.
  The SCM Solution: SCM systems maintain a complete history of every change. If a
bug is introduced, developers can easily "roll back" to a previous, stable version of the
code. This allows them to quickly revert to a working state and then fix the bug in a
controlled manner.

3. Providing a Complete History

 The Problem: Without a clear history, it's impossible to know who made a change,
when it was made, and, most importantly, why. This lack of transparency makes it
hard to understand the evolution of the codebase and holds developers accountable.

 The SCM Solution: Every change (or "commit") in an SCM system is recorded with a
timestamp, the author's name, and a descriptive message. This creates a detailed
audit trail of the entire project, making it easy to track the origins of a bug or
understand the rationale behind a specific design decision.

4. Enabling Efficient Collaboration

 The Problem: Sharing code and merging changes without a dedicated system is a
manual and tedious process, often involving emailing code snippets or using shared
folders. This can lead to confusion, code fragmentation, and a lack of a single source
of truth.

 The SCM Solution: SCM systems provide a structured way for teams to collaborate.
Features like branching allow developers to work on new features in isolation, and
pull requests (or merge requests) enable a formal review process before changes are
integrated into the main codebase.

2. The History of Source Code Management

Version control systems have evolved from simple local systems to powerful distributed
systems.

 Early Days (Local VCS): Systems like SCCS and RCS stored revision history on a
single machine, making collaboration difficult.

 Centralized VCS (CVCS): Tools like CVS and Subversion introduced a central server
where all changes were committed. While this improved collaboration, the central
server was a single point of failure.

 Distributed VCS (DVCS): Git, Mercurial, and others revolutionized SCM by allowing
every developer to have a full copy of the repository on their local machine. This makes
them faster, more robust, and enables powerful workflows.

The History of Source Code Management (SCM)

The evolution of Source Code Management (SCM) systems mirrors the increasing complexity
and scale of software development. It has progressed from simple, single-user tools to today's
powerful, globally distributed systems. This evolution can be categorized into three distinct
eras.

1. Early Days (Local Version Control Systems - Local VCS)

In the earliest days of version control, developers relied on systems that stored the entire
revision history on their local machine. There was no concept of a central server, making
collaboration difficult.
  Concept: The entire version history was contained within a developer's local machine,
often in a special database or folder. This allowed developers to track their own
changes and revert to older versions.

 Examples: Systems like SCCS (Source Code Control System) and RCS (Revision
Control System) were pioneering tools in this era.

 Limitations: The biggest drawback was the complete lack of collaboration. There was
no way to easily share changes with other developers, and if a hard drive failed, all
history was lost.

2. Centralized Version Control Systems (CVCS)

The advent of the internet and networked computers led to the development of Centralized
Version Control Systems. These systems introduced a single, central server that hosted the
repository.

 Concept: All developers would connect to a central server to check out files and
commit their changes. The entire version history resided on this single server.

 Examples: Popular CVCS tools included CVS (Concurrent Versions System) and
Subversion (SVN).

 Advantages: CVCS significantly improved collaboration. Developers could see each

other's changes and a single, shared source of truth was established.

 Disadvantages: CVCS had two major weaknesses:

1. Single Point of Failure: If the central server went down, developers couldn't
commit changes or collaborate. If the server's database was corrupted, the
entire project's history could be lost.

2. Network Dependency: Developers needed to be connected to the network to

perform most version control operations.

The following image illustrates the architecture of a Centralized Version Control System:

[invalid URL removed]

3. Distributed Version Control Systems (DVCS)

The latest and most revolutionary evolution in version control is the Distributed Version
Control System. DVCS completely changed the model by giving every developer a full copy of
the entire repository.

 Concept: Instead of just checking out the latest version, developers clone the entire
repository, including its full history, to their local machine. They can work, commit
changes, and even create branches completely offline.

 Examples: Git and Mercurial are the most prominent examples of DVCS.

 Advantages:

o Redundancy: Every developer's local repository acts as a full backup.

o Speed: Most operations are performed locally, making them incredibly fast.

o Offline Work: Developers can work without a network connection.

o Powerful Workflows: The distributed nature enables advanced, flexible

workflows and branching strategies.
The evolution from Local to Distributed VCS has made SCM more robust, faster, and more
integral to modern software development workflows.

3. Roles, Code, and SCM System

In a typical SCM environment, the roles and their relationship to code are well-defined:

 Developers: Write code and commit their changes to the SCM system.

 Repository: The central database where the source code and its entire history are
stored.

 Workflows: The set of rules and practices (e.g., Gitflow, GitHub Flow) that dictate how
teams should collaborate on the code.

 Code Reviewers: Other developers who review the changes before they are merged
into the main codebase.

Roles, Code, and the SCM System: A Detailed Breakdown

In a modern software development environment, a Source Code Management (SCM) system

provides a structured framework for managing code. This framework clearly defines roles and
the processes they follow to ensure a smooth, collaborative, and efficient workflow.

1. Developers

 Role: Developers are the primary actors in the SCM system. Their main responsibility
is to write new code, fix bugs, or implement new features.

 Relationship to Code: Developers interact directly with the code in their local
working directory. Once they have completed a set of changes, they "commit" those
changes to the SCM system, which records their work, along with a descriptive
message, into the project's history.

2. Repository

 Role: The repository is the central, authoritative database where the entire source
code and its complete history are stored.

 Relationship to Code: The repository is the single source of truth for the project. It
contains every version of every file, allowing any developer to retrieve the latest version
of the code or any previous version from the project's history. For distributed systems
like Git, a remote repository serves as the shared reference point for all developers.

3. Workflows

 Role: Workflows are the set of rules, practices, and guidelines that dictate how a team
should use the SCM system to collaborate.

 Relationship to Code: Workflows define a structured process for handling code

changes. For example:

o Gitflow is a workflow that uses long-lived branches for development and

releases, as well as short-lived feature branches.

o GitHub Flow is a simpler workflow that uses a single main branch and feature
branches for all new work. These workflows ensure that changes are handled
consistently and that the main codebase remains stable.

4. Code Reviewers
  Role: Code reviewers are other developers on the team (often senior developers or
peers) who are responsible for reviewing code changes before they are integrated into
the main codebase.

 Relationship to Code: Before a developer's changes are merged, they submit a "pull
request" (or "merge request"). The code reviewers then examine the changes for
quality, correctness, adherence to coding standards, and potential bugs. They provide
feedback and can approve or request changes before the code is merged. This process
is crucial for maintaining code quality and sharing knowledge among the team.

The following image provides a high-level view of how these roles and components interact
within a typical SCM workflow. It shows the flow of code from a developer's local machine to
a remote repository, where it can be reviewed and eventually merged.

4. Version Control and GIT

Version Control is the overarching concept, while Git is a specific, powerful implementation
of a Distributed Version Control System (DVCS). Git’s architecture allows developers to work
offline and commit changes locally before pushing them to a remote server.

5. GIT Installation and Features

 Installation: Git is available for all major operating systems. You can download it
from the official Git website ([Link]).

 Key Features:

o Distributed: Every developer has a full copy of the repository.

o Branching and Merging: Creating branches for new features is fast and easy.

o Staging Area: A unique feature that allows developers to precisely control

what changes go into a commit.

o Integrity: Git uses a cryptographic hash (SHA-1) to ensure data integrity.

Version Control and GIT

Version Control is the overarching concept and practice of tracking and managing changes
to a set of files over time. It allows developers to revert to a previous version, compare different
versions, and see who made specific changes.

Git is a specific, powerful, and widely-adopted implementation of a Distributed Version

Control System (DVCS). Unlike older Centralized Version Control Systems (CVCS), Git's
architecture allows every developer to have a full copy of the entire repository—including its
complete history—on their local machine. This distributed nature is what makes Git so
robust, fast, and flexible.

The following image illustrates the fundamental difference between a Centralized and a
Distributed Version Control System.

[invalid URL removed]

GIT Installation and Features

Git’s architecture and features are what make it the industry standard for version control.

1. GIT Installation
  Process: Installing Git is a straightforward process. It is available for all major
operating systems.

o Windows: Download the installer from the official Git website ([Link]).

o macOS: You can install it via Homebrew (brew install git) or as part of the
Xcode Command Line Tools.

o Linux: Use your distribution's package manager (e.g., sudo apt-get install git
for Debian/Ubuntu or sudo dnf install git for Fedora).

 Verification: After installation, you can verify it by opening a terminal or command

prompt and typing git --version.

2. Key Features

 Distributed:

o Explanation: In a distributed system, every developer doesn't just check out

the latest snapshot of the code; they clone the entire repository. This means
they have a full, local copy of the project's history.

o Benefit: This provides redundancy, as every developer's machine acts as a full

backup. It also allows developers to work entirely offline and perform
operations like committing and branching without a network connection.

 Branching and Merging:

o Explanation: Git's branching model is its most powerful feature. Creating a

new branch is incredibly fast and cheap, allowing developers to create isolated
environments to work on new features or bug fixes without disrupting the
main codebase.

o Benefit: This enables flexible and efficient workflows, as developers can

experiment freely without risking the stability of the project. Once a feature is
complete, the branch can be easily merged back into the main branch.

o Image: This diagram visually represents the process of creating a branch for
a new feature and then merging it back into the main branch once the work is
complete.

[invalid URL removed]

 Staging Area:

o Explanation: Git has a unique "staging area" (also known as the "index") that
sits between your working directory (where you make changes) and your local
repository. You use the git add command to move changes from your working
directory to the staging area.

o Benefit: The staging area gives developers fine-grained control over what goes
into a commit. You can commit only a portion of your changes, allowing for
clean, logical commits that are easier to review and manage.

 Integrity:

o Explanation: Git is designed to ensure the integrity of the data it stores. It

uses a cryptographic hash function (SHA-1) to create a unique checksum for
every piece of data—files, commits, and tags. This checksum is used to identify
and verify the data.
 o Benefit: Because Git is designed to protect its data from corruption, it is an
extremely reliable system. It's impossible to change a file or commit without
Git knowing about it.

6. GIT Workflow

The Git workflow involves three main states for files:

1. Working Directory: The local directory where you are currently editing files.

2. Staging Area (Index): An area where you prepare a set of changes to be committed.

3. Git Repository: The final destination where your committed changes are stored.

The Git Workflow: Understanding the Three States of Files

The Git workflow is built around three fundamental states for files, which provide developers
with powerful control over their code changes. Understanding these states is crucial for
effectively using Git.

The following image provides a visual representation of how files move between these three
states in a typical Git workflow.

[invalid URL removed]

The Three States of the Git Workflow

1. The Working Directory

 Description: The Working Directory is the actual set of files that you see and work on
in your file system. It is the folder on your local computer where your project's code
resides. When you start making changes to files—writing new code, fixing bugs, or
adding new features—these changes are first made in your Working Directory.

 Status: Files in the Working Directory are considered modified or untracked by Git.
The git status command will show these files as having changes that are not yet staged
for a commit.

2. The Staging Area (or Index)

 Description: The Staging Area is a temporary holding area that acts as a bridge
between your Working Directory and your Git Repository. It is a unique and powerful
feature of Git that allows you to prepare a set of changes for a commit. You use the
git add <file> command to move changes from the Working Directory to the Staging
Area.

 Why It's Useful: The Staging Area gives you fine-grained control over what goes into
a commit. For example, if you've made changes to multiple files but only want to
commit the changes to one of them, you can git add just that file. This allows for clean,
logical commits that are easy to understand and review.

3. The Git Repository

 Description: The Git Repository is the final, permanent storage location for your
project's history. It is where all the committed changes, branches, and tags are stored.
When you make a commit using git commit, the changes from the Staging Area are
permanently recorded in the Git Repository.

 Status: Once changes are committed, they are part of the project's official history.
This is the state where the files are considered committed.
How the Workflow Connects

The process of saving your changes in Git involves moving files through these three states:

1. Modify: You make changes to files in your Working Directory.

2. Stage: You use git add to move the files you want to save to the Staging Area.

3. Commit: You use git commit to permanently save the staged files and their changes
to the Git Repository.

By understanding and using this three-state workflow, developers can maintain a clean,
organized, and reliable history of their project's codebase.

7. Working with a Remote Repository

A remote repository is a shared, central repository hosted on a platform like GitHub or GitLab.

 git clone: Creates a local copy of a remote repository.

 git fetch: Downloads changes from the remote repository without merging them.

 git pull: Fetches changes and automatically merges them into your local branch.

 git push: Uploads your local commits to the remote repository.

Working with a Remote Repository in Git

A remote repository is a version of your project that is hosted on the internet or a network. It
serves as a shared, central point of collaboration for all developers on a team and as a robust
backup of the entire project history. Platforms like GitHub, GitLab, and Bitbucket are
popular services that host these remote repositories.

The following commands are fundamental for interacting with a remote repository from your
local machine.

1. git clone

 Explanation: The git clone command is used to create a new local copy of an existing
remote repository. When you clone a repository, Git downloads the entire project
history, including all its branches, and sets up a local copy on your machine. This is
typically the first command you use when starting to work on a project.

 When to Use: When you want to get a complete local copy of a project that already
exists on a remote server.

 Diagram: The image below illustrates the process of cloning a remote repository to
your local machine.

[invalid URL removed]

2. git fetch

 Explanation: The git fetch command downloads new changes from the remote
repository without automatically merging them into your local branch. It updates your
local copy of the remote branch (origin/main, for example), but it does not touch the
files in your working directory.

 When to Use: When you want to see what changes have been made by other
developers without immediately integrating them into your work. This allows you to
inspect the changes before deciding to merge them.
3. git pull

 Explanation: The git pull command is a combination of git fetch and git merge. It first
downloads the latest changes from the remote repository and then automatically
merges them into your current local branch.

 When to Use: When you are ready to integrate the latest changes from the remote
repository into your local branch. It's a quick way to ensure your local repository is
up to date with the remote.

 Relationship to fetch: You can think of git pull as a shortcut. It's equivalent to
running git fetch followed by git merge.

4. git push

 Explanation: The git push command is used to upload your local commits to the
remote repository. It sends your changes to the remote server, making them available
to other developers.

 When to Use: After you have committed your changes locally and are ready to share
them with the rest of the team. A git push command only sends the commits that are
not yet on the remote repository.

The following diagram provides a visual overview of how the git fetch, git pull, and git push
commands interact between your local repository and the remote repository.

8. GIT Commands

Some of the most common Git commands are:

 git init: Initializes a new Git repository.

 git add <file>: Adds a file to the staging area.

 git commit -m "message": Commits staged changes with a message.

 git status: Shows the status of the working directory and staging area.

 git branch: Lists, creates, or deletes branches.

 git checkout <branch>: Switches to a different branch.

 git merge <branch>: Merges changes from one branch into another.

Common Git Commands: A Detailed Guide

Git is a powerful command-line tool, and mastering its basic commands is essential for
effective version control. Here is a detailed breakdown of some of the most common Git
commands and their role in the workflow.

The following image provides a high-level overview of the Git workflow, which helps in
understanding where each command fits into the process of saving changes.

[invalid URL removed]

1. git init

 Explanation: The git init command is used to initialize a new, empty Git repository.
When you run this command in a directory, Git creates a hidden .git folder. This folder
 contains all the necessary files that Git uses to track the project's history,
configuration, and state.

 Purpose: This is typically the first command you run when you start a new project
that you want to put under version control.

 Example:

Bash

mkdir my_new_project

cd my_new_project

git init

2. git add <file>

 Explanation: The git add command moves changes from your working directory to
the staging area. The staging area acts as a temporary holding space where you can
prepare a set of changes before committing them.

 Purpose: This command gives you fine-grained control over what changes will be
included in your next commit. You can add specific files or all changed files to stage
them for a commit.

 Example:

Bash

# Add a single file to the staging area

git add [Link]

# Add all changed files to the staging area

git add .

3. git commit -m "message"

 Explanation: The git commit command permanently records the changes from the
staging area into your Git repository. Each commit represents a snapshot of your
project at a specific point in time. The -m "message" flag is used to provide a
descriptive message for the commit, which is crucial for understanding the history of
your project.

 Purpose: This command is how you save your work and create a permanent record of
your changes.

 Example:

Bash

git commit -m "Added initial HTML structure for the homepage"

4. git status
  Explanation: The git status command shows the status of your working directory and
staging area. It tells you which files have been modified, which have been staged for a
commit, and which are untracked.

 Purpose: This is a vital command for getting an overview of your current state. You
should run it frequently to know what's happening with your files.

 Example:

Bash

git status

5. git branch

 Explanation: The git branch command is used to list, create, or delete branches.
Branches are a core feature of Git that allows you to work on new features or bug fixes
in an isolated environment without affecting the main codebase.

 Purpose: This command is used to manage the different lines of development in your
project.

 Example:

Bash

# List all branches in the repository

git branch

# Create a new branch named 'feature-x'

git branch feature-x

# Delete the 'old-branch'

git branch -d old-branch

6. git checkout <branch>

 Explanation: The git checkout command is used to switch from your current branch
to another one. When you check out a branch, Git updates your working directory to
match the files of that branch.

 Purpose: This command allows you to seamlessly switch between different lines of
work.

 Example:

Bash

# Switch to the 'feature-x' branch

git checkout feature-x

7. git merge <branch>

 Explanation: The git merge command is used to integrate changes from one branch
into another. For example, after you have finished developing a new feature on a
branch, you can merge it into the main branch to make it part of the main codebase.

 Purpose: This command is the final step in integrating changes and is a cornerstone
of collaborative workflows.

 Image: This diagram shows the process of a feature being developed on a separate
branch and then merged back into the main branch.

[invalid URL removed]

 Example:

Bash

# Ensure you are on the 'main' branch

git checkout main

# Merge the changes from 'feature-x' into 'main'

git merge feature-x

9. GIT Branching

Branching is Git's killer feature. It allows developers to create isolated environments to work
on new features or bug fixes without affecting the main codebase.

 git branch <branch-name>: Creates a new branch.

 git checkout <branch-name>: Switches to that branch.

 git merge <branch-name>: Integrates the changes from the feature branch into the
main branch.

Git Branching: A Detailed Guide

Git branching is widely considered its most powerful feature. It allows developers to create
isolated environments to work on new features, bug fixes, or experiments without affecting
the stable, main codebase. Branches are essentially pointers to a specific commit in the
project's history, and Git makes creating and switching between them incredibly fast and
easy.

The Git Branching Workflow

A typical branching workflow follows these steps:

1. A developer starts on a stable branch, often named main or master.

2. They create a new, separate branch for their specific task (e.g., a new feature or a bug
fix).

3. They work on their new branch, making commits without impacting the main branch.

4. Once the work is complete, they merge the changes from their feature branch back
into the main branch.
This process ensures that the main branch always remains stable and ready for deployment.

The following diagram provides a visual representation of this branching and merging
workflow.

[invalid URL removed]

Key Git Branching Commands

Here are the essential commands used in the branching workflow:

1. git branch <branch-name>

 Explanation: This command is used to create a new branch. It creates a new pointer
that points to the same commit as your current branch. At this point, you are still on
the original branch; you have simply created a new one.

 Example:

Bash

# Create a new branch called 'new-feature'

git branch new-feature

2. git checkout <branch-name>

 Explanation: The git checkout command is used to switch to a different branch.

When you run this command, Git updates the files in your working directory to reflect
the state of the new branch, effectively allowing you to "jump" to that line of
development.

 Example:

Bash

# Switch to the newly created 'new-feature' branch

git checkout new-feature

 Shortcut: You can combine these two commands to create a new branch and switch
to it in one go with git checkout -b <branch-name>.

3. git merge <branch-name>

 Explanation: The git merge command is used to integrate changes from one branch
into another. You first switch to the branch you want to merge into (e.g., main), and
then you run git merge with the name of the branch you want to merge from (e.g.,
new-feature). This combines the histories of both branches.

 Example:

Bash

# First, switch to the 'main' branch

git checkout main

# Now, merge the 'new-feature' branch into the 'main' branch

git merge new-feature

  Conflict Resolution: If the same part of a file was changed in both branches, Git will
notify you of a merge conflict. You must manually resolve this conflict before you can
complete the merge.

10. GIT Staging and Collaboration

The staging area (git add) is a unique feature that allows developers to build a commit
piecemeal. This granular control is crucial for creating clean, logical commits.

 Collaboration: SCM platforms like GitHub and GitLab provide tools for collaboration,
such as Pull Requests (or Merge Requests). A pull request is a request to merge your
changes into the main codebase, where other developers can review and discuss the
changes before they are accepted.

Git Staging and Collaboration: A Detailed Guide

Git's power comes from its unique workflow and the tools it provides for collaboration. The
staging area is a key feature that gives developers granular control over their commits, while
pull requests on SCM platforms enable effective teamwork.

1. The Git Staging Area

 Explanation: The staging area (also known as the "index") is a middle ground between
your working directory (where you are making changes) and your local repository
(where commits are stored). Instead of committing all changes at once, you use the
git add command to move specific changes into this staging area.

 Granular Control: This "staging" process is a core feature that distinguishes Git from
many other version control systems. It allows you to build a commit "piecemeal." For
example, if you've been working on several unrelated changes, you can use git add to
select only the files or parts of files that belong to a single logical change.

 Benefit: This granular control is crucial for creating clean, logical commits. Each
commit becomes a self-contained unit of work that is easier to review, understand,
and, if necessary, revert.

The following image illustrates the three states of a file in Git: the Working Directory, the
Staging Area, and the Repository.

[invalid URL removed]

2. Collaboration with Pull Requests

 Explanation: While Git is a command-line tool, its power is fully realized when used
with SCM platforms like GitHub, GitLab, or Bitbucket. These platforms provide tools
that facilitate collaboration, with the most important being the Pull Request (PR) or
Merge Request (MR).

 What is a Pull Request? A Pull Request is a formal request to merge the changes
from your feature branch into another branch (usually the main or master branch).
It's a way of saying, "I have completed my work on this feature; please review my
changes and, if they're good, pull them into the main codebase."

 The Collaboration Process:

1. A developer creates a new feature branch and pushes it to a remote repository.

2. They create a Pull Request on the SCM platform.

 3. Other developers on the team are notified. They can review the code, leave
comments, and suggest changes.

4. Once the code is approved, a lead developer or maintainer can merge the Pull
Request, integrating the changes into the main branch.

This process ensures code quality, prevents bad code from entering the main branch, and
promotes knowledge sharing and discussion among the team.

UNIT TESTING & CODE COVERAGE

Unit testing and code coverage are practices that ensure the quality and reliability of software.

1. Unit Testing: Junit & nUnit

 Unit Testing: A software testing method where individual units or components of a

software application are tested to determine if they are fit for use.

 JUnit: A popular testing framework for Java. It provides annotations (e.g., @Test,
@BeforeEach) to write and run repeatable tests.

 nUnit: A similar testing framework for C# and other .NET languages. It is inspired by
JUnit and follows a similar structure for writing tests.

2. Code Coverage with SonarQube

 Code Coverage: A metric that measures the percentage of code that has been
executed by your tests. A high code coverage percentage suggests that a larger portion
of your codebase is being tested, which reduces the chance of undiscovered bugs.

 SonarQube - Code Quality Analysis:

 o SonarQube is an open-source platform that continuously analyzes and
measures code quality. It goes beyond simple code coverage to check for a wide
range of issues, including:

 Bugs: Identifying programming errors.

 Vulnerabilities: Finding security weaknesses.

 Code Smells: Detecting code that is difficult to maintain or

understand.

 Code Coverage: Reporting the percentage of code covered by tests.

o How it Works: SonarQube integrates with CI/CD pipelines. When a build

runs, SonarQube analyzes the code, and a report is generated on a central
dashboard. This gives developers and managers a clear view of the codebase's
health.

Question bank

Bloom's Level 1: Remembering

1. What is the primary purpose of a Source Code Management (SCM) system like Git?

2. List three essential Git commands used for the basic workflow of committing changes.

3. Define the term "version control" and explain why it is important for a software
development team.

4. What is the main function of a SonarQube server in a software development project?

5. State the purpose of a unit test in software development.

Bloom's Level 2: Understanding

1. Describe the difference between the git fetch and git pull commands, and explain when
you would use each.

2. Explain the concept of Git's three states: the working directory, the staging area, and
the local repository.

3. How does a Git branching strategy facilitate collaboration among multiple developers
working on the same project?

4. Summarize the role of Code Coverage in assessing the quality of a software project.
Why is a high code coverage percentage not the sole indicator of quality?

5. Describe how a tool like SonarQube analyzes code quality. What types of issues does
it typically report?

6. Explain the purpose of the Git staging area and describe how a developer uses it to
selectively include or exclude files from a commit.

7. Describe the concept of Git branching. Explain how creating and merging branches is
a fundamental aspect of collaborative development workflows.

8. Summarize the importance of code coverage. Explain how a low code coverage
percentage, as reported by a tool like SonarQube, can impact the reliability and
maintainability of a software project.

9. Describe the synchronization process between a local and a remote Git repository.
Explain the purpose of the commands used to retrieve new commits from a remote
repository and integrate them with local changes.
 10. Explain the difference between a "Code Smell" and a "Bug" as identified by a code
quality analysis tool like SonarQube. Describe the implications of each on a project's
long-term health.

Bloom's Level 3: Applying

1. A developer has just made several changes to their local files and wants to commit
them. The developer made a mistake in one of the files and wants to remove it from
the next commit without reverting the changes. Which Git commands would the
developer use to accomplish this, and in what order?

2. You are tasked with introducing a new feature to a project without disrupting the
main codebase. Propose a Git branching strategy to manage this process, including
the specific commands and workflow steps for creating a new branch, making
changes, and merging it back into the main branch.

3. A project's CI/CD pipeline has a step for running Junit tests. If the build fails with a
"low code coverage" error from SonarQube, what specific actions would you
recommend the development team take to address this issue?

4. A developer wants to submit a change to a remote repository but discovers that the
remote repository has newer commits that are not in their local repository. Explain
the sequence of Git commands they must use to successfully synchronize their local
changes with the remote repository.

5. You have been asked to evaluate the quality of a new team's code. You set up
SonarQube and find a high number of "Code Smells" but a low number of "Bugs."
Based on this information, how would you interpret the results and what
recommendations would you provide to the team?