UNIT II

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. What is
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.

THE NEED FOR SOURCE CODE CONTROL:

Source Code Control (also called Source Code Management or Version Control) is used to
manage and track changes made to software code. It is an important part of software
development because it helps developers work safely and efficiently.
1. Tracking Changes
Source code control helps keep a record of every change made to the code. It stores information
about what changed, who changed it, and when it was changed. This complete history helps
developers understand how the project has evolved and makes it easy to trace the source of
errors or bugs.
2. Restoring Previous Versions
If new changes cause problems or break the code, developers can easily go back to an older
version. This ability to undo or rollback changes ensures that the project always has a stable
version to return to, reducing risk during development.
3. Preventing Loss of Code
Accidents like system crashes, deletion of files, or overwriting work can cause developers to
lose important code. Source code control acts as a backup system where earlier versions are
always stored safely and can be recovered whenever needed.
4. Supporting Team Collaboration
When multiple developers work on the same project, source code control helps avoid conflicts
and confusion. Each developer can work on their own part without disturbing others. Their
changes can later be combined in an organized way, ensuring smooth teamwork.
5. Working with Branches
Source code control allows developers to create branches to work on new features, fix bugs, or
test ideas without affecting the main project. Once the changes are successful, they can be
merged back into the main codebase safely.
6. Improving Code Quality
Using source code control, developers can review each other’s changes and maintain consistent
coding standards. This increases the overall quality of the software and reduces the chances of
bugs and errors.
7. Supporting Modern Development Practices
Modern practices like Continuous Integration (CI), Continuous Deployment (CD), and DevOps
depend on source code control. Automated tools use version control to detect changes, test the
code automatically, and deploy it efficiently.
8. Ensuring Organization and Safety
Source code control brings structure to software development. It ensures that code is organized,
safe, easy to manage, and protected against mistakes. Without it, handling large projects would
be very difficult and risky.

HISTORY OF SOURCE CODE MANAGEMENT

1. First Generation: Manual File Tracking (1960s–1970s)

In the early days of computing, programmers stored code on punch cards and magnetic tapes.
There were no tools to track changes, and developers had to manage versions manually.
Collaboration was almost impossible because files were easily misplaced or overwritten. As
software became larger and more complex, developers needed a better way to manage and track
changes.
2. Second Generation: Early Version Control Systems (1970s–1980s)
To solve the problems of manual tracking, the first official version control systems appeared.
In 1972, AT&T Bell Labs introduced SCCS (Source Code Control System). It allowed
developers to record file versions and see what was changed over time.
In 1982, RCS (Revision Control System) was created, improving version tracking and storing
a clear history of changes. However, these systems used a “check-in/check-out” model where
only one developer could edit a file at a time. They were suitable only for small teams and
small projects.
3. Third Generation: Centralized Version Control (1980s–2000s)
As collaboration needs increased, centralized version control systems became popular.
In 1986, CVS (Concurrent Versions System) was introduced. It allowed multiple developers
to work together by storing all code on a central server. This made teamwork easier, but still
had limitations: if the central server failed, everyone was blocked.
In 2000, Subversion (SVN) was developed to improve CVS. SVN offered better reliability,
atomic commits, and easier management, but it was still centralized, meaning developers
depended heavily on a single server and had limited offline capability and branching features.
4. Fourth Generation: Distributed Version Control (2000s–Present)
The major revolution in source code management came with distributed version control
systems (DVCS). These systems solved the biggest weakness of centralized systems by giving
every developer a complete copy of the repository, including full history, branches, and files.
In 2005, Git, created by Linus Torvalds, transformed the entire software industry. Git
introduced fast branching, offline work, local history, flexible workflows, and a very reliable
system for large-scale development. Because of its speed, power, and reliability, Git became
the global standard for version control.
5. Fifth Generation: Cloud-Based Collaboration Platforms (2008–Present)
With Git’s popularity, cloud platforms were built to support online collaboration.
GitHub (2008), GitLab, Bitbucket, and Azure DevOps made Git easier to use by providing
features like pull requests, issue tracking, team permissions, project boards, CI/CD automation,
and remote repository hosting. These platforms do not replace Git; instead, they enhance Git
with modern, collaborative workflows that support both open-source and enterprise
development.

ROLES AND CODE:

Roles:
1. Developer
The Developer is responsible for writing, editing, and updating the source code. They work in
the working directory, create new files, fix bugs, and add new features. Developers commit
their changes and push their work to the repository. They may also create branches to work
independently without affecting the main project.
2. Reviewer / Maintainer
The Reviewer (also called Maintainer) checks the code written by developers to ensure
correctness, readability, and quality. They review commits, inspect changes, suggest
improvements, and approve or reject merge requests. Their role is important for maintaining
code standards and preventing faulty code from entering the main branch.
3. Release Manager
The Release Manager is responsible for preparing the project for deployment. They ensure that
the code is stable, tested, and ready for production. They create version tags, manage release
branches, and coordinate with developers to fix last-minute issues. Their job is to make sure
that only reliable and error-free code is released to users.
4. Admin / Repository Owner
The Admin or Repository Owner manages the overall repository structure and settings. They
control who can read, write, or modify the project, set branch protection rules, enable security
policies, and manage backups. They ensure that the repository is safe, organized, and accessible
only to authorized team members.
5. QA Tester (Optional Role in Some Teams)
In many teams, a QA Tester works closely with SCM processes. Their role is to test the code,
report bugs, and ensure that the application works as expected. Although they do not usually
commit code, they depend on version-controlled builds for testing.
Code Flow in Source Code Management
1. Working Directory
The working directory is where developers actually write and edit the source code. It contains
the real files and folders of the project. Any change a developer makes—such as creating a new
file, modifying a file, or deleting a file—happens in the working directory. At this stage, the
changes are not yet tracked permanently by Git. The working directory is simply the place
where development work happens before the changes are prepared for saving.
2. Staging Area (Index)
The staging area is a temporary holding area where changes are reviewed and prepared before
they become part of the project history. When a developer runs the command git add, the
selected files move from the working directory into the staging area. This allows the developer
to choose which changes should go into the next commit. Only the changes in the staging area
will be included in the commit. This step helps developers organize their commits carefully
and avoid saving unwanted or incomplete changes.
3. Local Repository
The local repository is where Git permanently stores the committed versions of the project.
When a developer runs git commit, all changes from the staging area are saved in the local
repository as a new version with a unique commit ID. The local repository contains the full
history of the project, including all previous commits, authors, messages, and timestamps. This
makes it possible to go back to any earlier version, compare changes, and track the progress of
development over time.
4. Remote Repository
In collaborative projects, a remote repository is used to share code with other developers. It is
hosted on platforms like GitHub, GitLab, or Bitbucket. Developers push their local commits to
the remote repository using git push, and pull updates from others using git pull. The remote
repository helps teams work together, maintain a common project version, and back up the
code in the cloud.

SOURCE CODE MANAGEMENT SYSTEMS AND MIGRATIONS

A Source Code Management (SCM) system is a tool used to track and manage changes made
to software source code. It helps developers collaborate, maintain code history, compare
versions, undo mistakes, and organize development using branches and merges. Examples of
SCM tools include Git, SVN, CVS, Mercurial, and Perforce.
Migration
SCM migration refers to moving from one version control system to another. Most migrations
are from older centralized systems like CVS or SVN to modern distributed systems like Git.
The main reasons include improved branching and merging, better collaboration, faster
performance, support for CI/CD pipelines, and integration with cloud platforms such as
GitHub, GitLab, or Bitbucket.
The migration process typically involves analysing the existing repository, converting the
commit history, preserving tags and branches, mapping user permissions, and checking the
accuracy of the migrated data. It may also include reorganizing large codebases and training
team members on the new system.
Benefits of Successful Migration
A successful SCM migration modernizes the development workflow, increases productivity,
enhances collaboration, and maintains complete historical data while enabling teams to use
more efficient and scalable tools.

VERSION CONTROL & GIT

Version Control
Version control is a system that records and manages changes made to source code over time.
It keeps track of every modification so developers can view previous versions, compare
differences, undo mistakes, and understand how the project has evolved. Version control also
allows multiple developers to work on the same project without overwriting each other’s work.
It ensures an organized, safe, and traceable way of handling code throughout the development
process.
Version control is important because it:
• Stores the complete history of changes
• Allows restoring earlier versions (rollback)
• Supports teamwork and collaboration
• Helps merge contributions from different developers
• Ensures the project remains stable and organized
Without version control, development becomes confusing and risky, especially in team
environments.
GIT
Git is a distributed version control system (DVCS) created by Linus Torvalds in 2005. It is
the most widely used version control tool in the world. Git allows every developer to have a
full copy of the repository, including the entire code history, on their local machine. This makes
Git fast, reliable, and capable of working offline.
 1. Each developer has a working copy where they edit files and a local repository where
their commits are stored.
2. All developers have their own full copy of the repository on their own computers. This
is why Git is called a distributed system.
3. Developers make changes in the working copy and then commit those changes to their
local repository. This does not need the internet.
4. There is also a remote repository on a server (like GitHub or GitLab) that acts as a
common place for sharing code.
5. When a developer wants to share their new work, they push their commits from the
local repository to the remote server.
6. When a developer wants to get updates made by others, they pull the latest commits
from the remote repository into their own local repository.
7. This push and pull process keeps all developers updated with each other's changes while
still letting them work independently on their own machines.

GIT INSTALLATION
Installing Git on Windows starts by downloading the official installer from the Git website and
running the setup wizard. The user accepts the license, selects the installation folder, and keeps
the default recommended components such as Git Bash and Git GUI. During installation, Git
asks for a default editor, how Git should be added to the system PATH, and whether to use
OpenSSL for secure connections. It also configures line-ending settings and chooses the
terminal emulator (usually Git Bash/MinTTY). After completing these steps, Git installs on the
system. Once finished, Git Bash is available, and the installation can be verified using the git -
-version command. The final step is setting your username and email, which allows Git to
identify your commits.

Installation Steps on Windows

 1. Download Git
Visit [Link] and download Git for Windows.
2. Run the Installer
Open the .exe file → Accept the license → Click Next.
3. Choose Default Settings
Keep the default installation folder and components (Git Bash, Git GUI).
4. Basic Configuration
o Choose a default editor (VS Code or Nano)
o Select “Git from the command line”
o Use OpenSSL for HTTPS
o Keep default line-ending settings
5. Terminal and Credentials
o Choose Git Bash (MinTTY) as the terminal
o Keep Git Credential Manager enabled
6. Install and Verify
o Click Install
o Open Git Bash and run:
o git --version
o Set username and email:
o git config --global [Link] "Your Name"
o git config --global [Link] you@[Link]

GIT FEATURES
1. Distributed Version Control
Git is a distributed system, meaning every developer has a full copy of the repository, including
all files and complete history. This makes Git fast, reliable, and usable even without an internet
connection.
2. Fast Performance
Git performs operations like commit, merge, branch, and checkout very quickly because most
actions happen locally on the user’s machine.
3. Strong Branching and Merging
Git allows developers to create lightweight branches easily for new features, bug fixes, or
testing. These branches can be merged back into the main project smoothly, supporting flexible
workflows.
4. Data Integrity
Git uses SHA-1 hashing to protect the data. Every commit has a unique ID, ensuring that code
cannot be changed without detection. This makes Git secure and trustworthy.
5. Offline Work Support
Most Git operations (commit, log, branch, diff) can be done offline. Developers do not need a
server connection to work. Only push and pull require network access.
6. Efficient Storage
Git stores changes efficiently by saving only the differences (deltas) rather than full files each
time. This reduces storage size and improves performance.
7. Staging Area (Index)
Git offers a staging area where changes can be reviewed and selected before making a commit.
This allows precise control over what is included in each version.
8. Collaboration with Remote Repositories
Git supports remote servers like GitHub, GitLab, and Bitbucket. Developers can push their
local changes and pull updates from others, enabling team collaboration.
9. Complete History and Traceability
Git keeps a full history of commits with details such as author, timestamp, and commit
message. This helps understand the evolution of the project and trace issues.
10. Free and Open-Source
Git is free to use and open-source, which makes it accessible to everyone and widely supported
across platforms.

GIT WORKFLOW

1. Working Directory
The working directory is where developers edit, create, or delete files. All changes begin here.
These changes are not yet tracked by Git and must be moved forward to be saved.
2. Staging Area
The staging area is the next step, where selected changes are prepared before saving. Using git
add, developers move files from the working directory to the staging area. Only staged changes
will be included in the next version.
3. Local Repository
The local repository stores committed versions of the project. When developers run git
commit, the staged changes are permanently saved into the local repository. This creates a new
entry in the project’s version history.
4. Remote Repository
The remote repository is a shared version of the project stored on a server like GitHub, GitLab,
or Bitbucket. It allows collaboration between multiple developers on the same codebase.
5. Push Operation
Using git push, developers send their committed changes from the local repository to the
remote repository. This makes their updates available to the entire team.
6. Pull Operation
Using git pull, developers download the latest changes from the remote repository to their local
repository. This keeps their local project up to date with others' work.
7. Checkout Operation
The git checkout command is used to switch between branches or restore files. In the diagram,
it shows movement backward—from the repository back to the working area—allowing
developers to access older or different versions of files.
WORKING WITH A REMOTE REPOSITORY
1. Purpose of a Remote Repository
A remote repository is a shared version of a project stored on an online server such as GitHub,
GitLab, Bitbucket, or Azure DevOps. It allows multiple developers to work together by
providing a central place where everyone can upload their changes and download updates from
others.
2. Cloning a Remote Repository
The workflow usually begins by copying an existing project from the server using git clone.
Cloning creates a complete local copy of the project, including its history, files, and branches.
3. Pushing Local Changes to Remote
After making changes and committing them locally, developers use git push to upload their
commits to the remote repository. This makes their work available to the entire team.
4. Getting Updates from the Remote
To stay updated with the team’s work:
• git fetch downloads new changes from the remote without merging them.
• git pull downloads and automatically merges the latest changes into the current branch.

5. Managing Remote Connections

Git allows developers to work with multiple remotes.
• git remote add – add a new remote server
• git remote -v – view existing remote connections
This is useful when working with different servers or collaborating with other teams.
6. Working With Remote Branches
Developers often create branches locally and push them to the remote repository for others to
review or work on. Platforms like GitHub and GitLab support collaboration through pull
requests or merge requests, where team members review and approve code before it is
merged.
Remote repositories help teams coordinate their work, provide a centralized backup of the
project, enable distributed development, and support tools like issue tracking, CI/CD pipelines,
and versioned releases. They are essential for modern team-based software development.

GIT COMMANDS
1. Commands Used in the Workspace
These commands work on files before they enter staging.
• git add / mv / rm
Moves new, modified, or deleted files from the workspace to the staging area.
• git reset
Removes a file from the staging area and returns it back to the workspace.
• git diff
Shows differences between workspace changes and the last committed version.
• git diff HEAD
Shows differences between the workspace and the most recent commit (HEAD).
2. Commands Used Between Workspace and Local Repository
• git commit -a
Automatically stages all modified and deleted files (skips "git add") and commits them
to the local repository. (Adds + commits in one step)

3. Commands Used in the Staging Area

These commands act specifically on staged changes.
 • git commit
Saves staged changes permanently in the local repository.
• git reset
Moves the repository back to a previous commit. This changes the staging area and
workspace depending on options used.

4. Commands Working with the Local Repository

These commands involve the local Git history.
• git push
Sends commits from the local repository to the remote repository so others can access
them.

5. Commands Working with the Remote Repository

These commands bring information from the remote server.
• git fetch
Downloads updates from the remote repository without merging them into the working
files.
• git clone / git pull
git clone → copies a full remote repository into a new local folder.
git pull → downloads and merges the latest remote changes into the local repository.
GIT BRANCHING
• Git branching allows developers to create separate lines of development within the
same project.
• A branch is an independent workspace for developing features, fixing bugs, or
experimenting safely.
• Branching keeps the main/master branch stable, preventing unfinished work from
affecting production code.
• Each branch provides isolated development, so changes do not interfere with the rest
of the project.
• Git branches are lightweight, allowing fast creation and quick switching between
branches.
• After completing work, the branch is merged into the main branch to integrate stable,
tested changes.
• Common branching strategies include:
o Feature branches
o Release branches
o Hotfix branches
• Git helps resolve merge conflicts when two branches change the same parts of a file.
• Benefits of branching include:
o Parallel development
o Safe testing and experimentation
o Improved teamwork
o Clean and organized code history
 o Protection of production-ready code

GIT STAGING AND COLLABORATION

1. Git Staging
Git staging (also called the staging area or index) is an intermediate place where changes are
collected before they are committed. It acts as a preparation zone between the working
directory and the local repository.
When developers edit files in the working directory, the changes are not automatically saved
in Git’s history. Using git add, selected changes are moved to the staging area. This allows
developers to choose exactly which updates should be included in the next commit.
Control Over Commits
Staging gives fine-grained control. Developers can:
• include only specific changes
• avoid adding unwanted modifications
• group related changes into one commit
• split large changes into multiple commits
This leads to clean, meaningful, and professional commit histories.
2. Git Collaboration
Git collaboration allows multiple developers to work together on the same project using remote
repositories hosted on platforms like GitHub, GitLab, Bitbucket, or Azure DevOps. It
enables distributed teams to share, review, update, and merge code efficiently.
Collaboration usually begins by cloning a remote repository. This creates a full local copy of
the project. Developers then work on features or fixes in their local branches and commit their
changes.
Sharing Work with Others
After committing locally, developers use git push to upload their updates to the remote
repository. This makes their work available to teammates.
Receiving Updates
To get the latest changes from others, developers use:
• git pull → download + merge changes
• git fetch → download changes without merging
This keeps the local copy synchronized with the remote project.
Branching in Collaboration
Team members usually create their own branches for features or bug fixes. They then submit
their work for review through:
• pull requests (GitHub)
• merge requests (GitLab/Bitbucket)
These tools allow:
• code review
• testing
• discussion
• approval before merging
This maintains high code quality and avoids errors in the main branch.
UNIT TESTING – CODE COVERAGE
Unit Testing
Unit testing is a software testing method where individual components or small units of code—
such as functions, methods, or classes—are tested separately. The goal is to ensure each unit
works correctly before combining them into the full application.
Code Coverage
Code coverage is a metric used to measure how much of the program’s source code is executed
during testing. It shows which parts of the code are tested and which parts are not.
Types of Code Coverage
1. Statement Coverage – checks whether each line of code has been executed
2. Branch Coverage – checks whether each decision path (if/else) has been tested
3. Function/Method Coverage – verifies that each function is called during tests
4. Condition Coverage – ensures each condition within a decision is tested
5. Loop Coverage – checks loops with zero, one, and many iterations

JUnit (Java Unit Testing Framework)

JUnit is a popular unit testing framework used for testing Java applications. It allows
developers to write test cases to check whether individual methods or classes work correctly.
JUnit automates the testing process and helps maintain high-quality Java code.
Purpose of JUnit
JUnit is used to:
• Test small units of Java code
• Detect bugs early
• Ensure code behaves as expected
• Automate repetitive tests
• Support Test-Driven Development (TDD)
JUnit makes it easier to validate Java program logic before the full application is built.
Features of JUnit
• Annotations like @Test, @BeforeEach, @AfterEach
• Assertions to compare expected and actual results
• Automatic test execution
• Test suites to group tests
• Easy integration with IDEs (Eclipse, IntelliJ)
• Supports TDD workflows
These features help developers create structured and maintainable tests.
4. Important JUnit Annotations
• @Test – marks a method as a test case
• @BeforeEach – runs before every test
• @AfterEach – runs after every test
• @BeforeAll – runs once before all tests
• @AfterAll – runs once after all tests
 • @Disabled – skips a test temporarily
These annotations control how tests are executed.
5. Assertions in JUnit
Assertions check whether the expected output matches the actual output. Common ones
include:
• assertEquals() – checks equality
• assertTrue() / assertFalse() – checks boolean conditions
• assertNotNull() / assertNull() – checks object state
• assertThrows() – verifies exceptions
Assertions form the core of JUnit tests.
6. Working of JUnit
1. Developer writes test methods using @Test
2. JUnit runs all test methods
3. Each test compares expected vs. actual results
4. Failed tests show errors to help debugging
5. Passed tests confirm correct behavior
JUnit provides a structured and automated testing flow.

NUNIT (.NET UNIT TESTING FRAMEWORK)

NUnit is a popular unit testing framework used for testing .NET applications, especially those
written in C#. It allows developers to write test cases to verify that individual methods or
classes function correctly. NUnit automates the testing process and helps maintain high-quality
.NET code.
Purpose of NUnit
NUnit is used to:
• Test small units of .NET code (methods, classes)
• Detect bugs early in development
• Ensure code behaves as expected
• Automate repetitive testing tasks
• Support Test-Driven Development (TDD)
NUnit helps developers validate application logic before integrating components into a full
system.
Features of NUnit
• Attribute-based annotations like [Test], [SetUp], [TearDown]
• Powerful assertions for result validation
• Automatic test execution
• Test fixtures and test suites for grouping tests
• Parameterized tests
• Easy integration with IDEs (Visual Studio, Rider)
• Supports TDD workflows
These features help developers create well-organized and maintainable unit tests.

NUnit Attributes
 • [Test] – Marks a method as a test case
• [SetUp] – Runs before each test method
• [TearDown] – Runs after each test method
• [OneTimeSetUp] – Runs once before all tests
• [OneTimeTearDown] – Runs once after all tests
• [Ignore] – Skips a test temporarily
These attributes control the execution flow of NUnit tests.

Assertions in NUnit
Assertions are used to compare expected results with actual results. Common assertions
include:
• [Link]() – Checks equality
• [Link]() / [Link]() – Checks boolean conditions
• [Link]() / [Link]() – Checks object state
• [Link]() – Verifies that an exception is thrown
Assertions form the core validation mechanism in NUnit tests.

Working of NUnit
1. Developer writes test methods using [Test]
2. NUnit test runner executes all test cases
3. Each test compares expected and actual results using assertions
4. Failed tests display error messages for debugging
5. Passed tests confirm correct behavior
NUnit provides a structured and automated approach to unit testing in .NET applications.

CODE COVERAGE WITH SONARQUBE

• Code coverage indicates how much of the source code is executed during unit testing.
• SonarQube measures code coverage by analysing test reports generated by unit testing
tools to identify tested and untested parts of the code, helping improve software quality.
• SonarQube does not execute tests itself. It reads coverage reports generated by testing
tools such as JUnit, NUnit and displays the results in a graphical dashboard

Importance of Code Coverage

• Identifies untested code
• Helps detect bugs early
• Improves code reliability and maintainability
• Ensures critical logic is tested
• Supports quality standards in DevOps pipelines

Working of SonarQube:
1. Developers write unit tests
2. Tests are executed using a build or CI tool
3. A coverage report is generated
 4. SonarQube analyzes the report
5. Coverage percentage is displayed
6. Quality Gate checks if coverage meets the required level

A Quality Gate is a set of conditions such as:

• Minimum code coverage
• No critical bugs
• No security vulnerabilities
If conditions fail, the build can be blocked.

Types of Code Coverage in SonarQube

• Line Coverage – Percentage of executed lines
• Branch Coverage – Percentage of decision paths tested (if/else, switch)
• Condition Coverage – Percentage of boolean conditions evaluated

SONARQUBE – CODE QUALITY ANALYSIS

SonarQube is an automated code quality analysis tool used to inspect source code and
identify issues such as bugs, vulnerabilities, code smells, and low-test coverage. It helps
developers improve code reliability, security, and maintainability.
SonarQube performs static code analysis, meaning it analyses the code without executing it.
It supports multiple programming languages and integrates easily with CI/CD pipelines.
SonarQube Analyses:
• Bugs – Errors that may cause incorrect behavior
• Vulnerabilities – Security weaknesses in the code
• Code Smells – Poor coding practices affecting maintainability
• Code Coverage – Percentage of code tested by unit tests
• Duplications – Repeated code blocks