Coder Legion - Recent posts tagged unittest

Refactoring Go API Unit Tests: Breaking Down the Testing Monolith

Fri, 12 Jun 2026 13:40:37 +0000

The Concept

When building backend APIs in Go, testing isn't just about code coverage, it's about long-term maintainability. As an application grows, a naive approach to unit testing can lead to "testing monoliths" where test setup, mocking, HTTP routing, and core business logic verification are jammed into a single, massive file.

To keep a codebase agile, your testing architecture must mirror the separation of concerns found in your production code. This means isolating the code that handles incoming network requests from the code that executes your core domain logic.

The What

Initially, the testing structure for the API lived entirely within a single, monolithic *_test.go file. Inside this file, everything was dumped together: Only service-layer assertions no HTTP request simulation, and handwritten mock structs for both the repository and service layers.

const UUID = "12345678-1234-5678-1234-567890123456"

type StockMovementTest struct {
GetStockMovementsFunc         func(ctx context.Context, filters dto.BaseFilters) ([]models.StockMovement, int, error)
}

func (m *StockMovementTest) GetStockMovements(ctx context.Context, q dto.BaseFilters) ([]models.StockMovement, int, error) {
if m.GetStockMovementsFunc != nil {
return m.GetStockMovementsFunc(ctx, q)
}

return nil, 0, nil
}

func NewTestStockMovement(testStockMovementRepo *StockMovementTest) stock_movements.StockMovementService {
emailSvc := mocks.NewTestEmailService()
_, auditLogSvc := mocks.NewTestAuditService()
awsSvc := mocks.NewTestAWSService()

return stock_movements.NewStockMovementService(testStockMovementRepo, emailSvc, nil, auditLogSvc, awsSvc)
}

func TestGetStockMovements(t *testing.T) {
testStockMovementRepo := &StockMovementTest{}
testStockMovementSvc := NewTestStockMovement(testStockMovementRepo)

t.Run("Get StockMovements", func(t *testing.T) {
testStockMovementRepo.GetStockMovementsFunc = func(ctx context.Context, q dto.BaseFilters) ([]models.StockMovement, int, error) {
CheckStockMovementQuery(t, q)
return []models.StockMovement{{ProductID: 1}}, 1, nil
}

query := dto.Query{Search: "test", Limit: 10, Offset: 2, Sort: "change_amount ASC"}
_, _, err := testStockMovementSvc.GetStockMovements(context.Background(), query)

if err != nil {
t.Errorf("Expected no error, got %v", err)
}
})
}

The Why

While a single-file approach works for small projects, it quickly becomes an anti-pattern due to two major pain points:

Code Bloating: A single file containing setup, table-driven test cases, and verbose mock definitions quickly grows to thousands of lines, making it incredibly difficult to navigate and maintain.
Circular Dependencies (Cyclic Imports): In Go, packages cannot import each other transitively. When mocks, domain logic, and HTTP transport layers are tightly coupled in tests, you risk hitting compilation errors because the boundaries between your database, service, and handler packages become blurred.

Separating these concerns ensures that your tests remain clean, compile quickly, and scale alongside your features.

The How

To resolve this, the monolithic test file was refactored into a modular structure by breaking it down into three distinct components: mock.go, *_service_test.go, and *_handler_test.go.

📂 package_test/
├── 📄 mock.go              # Shared mock definitions for service & repository layers
├── 📄 *_service_test.go    # Pure business logic unit tests
└── 📄 *_handler_test.go    # HTTP, routing, and request/response validation tests

// mock.go

type MockAuthService struct {
//
}

func (m *MockAuthService) GenerateToken(userID int64) (string, error) {
return "", nil
}

func (m *MockAuthService) ParseToken(token string) (int64, error) {
return 0, nil
}

func (m *MockAuthService) Login(ctx context.Context, req LoginRequest) (string, error) {
return "", nil
}

func (m *MockAuthService) Register(ctx context.Context, req RegisterRequest) error {
return nil
}

type MockAuthRepository struct {
GetUsernameOrEmailFunc func(ctx context.Context, username string) (*models.Users, error)
RegisterFunc           func(ctx context.Context, user *models.Users) error
}

func (m *MockAuthRepository) Register(ctx context.Context, user *models.Users) error {
if m.RegisterFunc != nil {
return m.RegisterFunc(ctx, user)
}

return nil
}

func (m *MockAuthRepository) GetUsernameOrEmail(ctx context.Context, username string) (*models.Users, error) {
if m.GetUsernameOrEmailFunc != nil {
return m.GetUsernameOrEmailFunc(ctx, username)
}

return &models.Users{}, nil
}

// *_service_test.go

var testAuthRepo = &auth.MockAuthRepository{}
var testAuthSvc = NewTestAuth(testAuthRepo)

func NewTestAuth(testAuthRepo *auth.MockAuthRepository) auth.AuthService {
config := &config.Config{JWTSecretKey: "airconcure_jwt_key"}

return auth.NewAuthService(testAuthRepo, config)
}

func TestAuthServiceLogin(t *testing.T) {
t.Run("login credentials", func(t *testing.T) {
testAuthRepo.GetUsernameOrEmailFunc = func(ctx context.Context, username string) (*models.Users, error) {
passwordHash, _ := bcrypt.GenerateFromPassword([]byte("!Abc1234"), bcrypt.DefaultCost)
user := &models.Users{
ID:       1,
Username: "test_account",
Email:    "*Emails are not allowed*",
Password: string(passwordHash),
}

return user, nil
}

req := auth.LoginRequest{
Username: "rdev",
Password: "!Abc1234",
}

_, err := testAuthSvc.Login(context.Background(), req)
if err != nil {
t.Errorf("Expected no error, got %v", err)
}
})
}

// *_handler_test.go

var testAuthHandler = auth.NewAuthHandler(&auth.MockAuthService{})

func TestAuthHandlerLogin(t *testing.T) {
type loginRequest struct {
Username string `json:"username"`
Password string `json:"password"`
}

tests := []struct {
name           string
url            string
requestBody    any
expectedStatus int
}{
{
name: "complete login credentials",
url:  "/login",
requestBody: loginRequest{
Username: "rdev",
Password: "!Abc1234",
},
expectedStatus: http.StatusOK,
},
{
name: "login no password",
url:  "/login",
requestBody: loginRequest{
Username: "rdev",
Password: "",
},
expectedStatus: http.StatusBadRequest,
},
{
name: "login password less than minimum required",
url:  "/login",
requestBody: loginRequest{
Username: "rdev",
Password: "1234",
},
expectedStatus: http.StatusBadRequest,
},
}

for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
ctx, w := helpers.SetupJSONTestContext(t, http.MethodPost, tt.url, tt.requestBody)

testAuthHandler.Login(ctx)

if w.Code != tt.expectedStatus {
t.Errorf("Login() status = %d, resp = %v, want %d", w.Code, w.Body, tt.expectedStatus)
}
})
}
}

1. Centralizing Mocks (`mock.go`)

Instead of rewriting or copy-pasting mock implementations across multiple test files, all repository and service mock structs are declared once inside a dedicated mock.go file within the package. This acts as a single source of truth for test doubles.

2. Testing the Business Logic (`*_service_test.go`)

This file focuses strictly on testing the "under-the-hood" domain logic. Because the database/repository layer is mocked out via mock.go, these tests run entirely in-memory and are incredibly fast. They validate:

Data validation rules and edge cases.
Handling of incorrect data types or malformed payloads.
Domain-specific error handling and state transitions.

3. Testing the HTTP Transport Layer (`*_handler_test.go`)

This file is dedicated to verifying how the API interacts with the outside world. It uses Go's net/http/httptest package to simulate client requests, utilizing the service mocks so it doesn't trigger actual business logic. These tests validate:

HTTP status codes (e.g., 200 OK, 400 Bad Request, 429 Too Many Requests).
JSON serialization and deserialization.
Query parameters, URL parameters, and headers.
Middleware execution, such as rate limiters and authentication checks.

The Trade-offs

Like any architectural decision, moving to a multi-file testing structure comes with balancing factors:

Pros:

High Scannability: Developers looking for a routing bug only need to open the handler test, while those fixing a calculation bug can go straight to the service test.
Reduced Friction: Isolating the mocks prevents cyclic imports, keeping the Go compiler happy.
Clear Boundaries: It enforces discipline, ensuring you don't accidentally test HTTP mechanics inside a business logic test.

Cons:

Boilerplate Overhead: Managing multiple files and orchestrating mocks requires slightly more upfront configuration and file management.
Mock Maintenance: If a service interface changes, the central mock.go file must be manually updated (unless you adopt a code-generation tool like mockery).

In Layman's Terms

Imagine you run a busy restaurant.

Originally, your test kitchen had one giant manual that crammed the cook’s recipes, the waiter’s serving rules, and cardboard cutouts of fake customers all onto the same page. It was crowded and confusing.

With this new approach, you split that manual into three neat folders:

The Prop Room (mock.go): This is where you keep all your cardboard cutouts (fake databases and fake chefs) so you can reuse them whenever you need to practice.
The Kitchen Manual (*_service_test.go): This is where you test the food itself. Does it taste right? Is it missing an ingredient? You don't care how the waiter delivers it; you just care that the recipe works perfectly.
The Dining Room Manual (*_handler_test.go): This is where you test the customer experience. Did the waiter smile? Was the bill calculated correctly? Is the host stopping too many people from rushing the door at once (rate limiting)? You don't care how the kitchen cooked the food here; you just care that the service at the table is seamless.

Conclusion

While software architecture preferences always vary depending on team conventions, decoupling your tests by responsibility is a proven strategy for Go applications. By isolating your HTTP logic from your business logic and centralizing your mocks, you eliminate code bloat, wipe out cyclic imports, and create a test suite that is easy to read, navigate, and maintain.

[BOOK REVIEW] Meszaros G., xUnit Test Patterns (2007)

Thu, 13 Nov 2025 08:47:56 +0000

This is the teaser post of the original review that is pretty detailed, containing images and diagrams.

Meszaros G., xUnit Test Patterns (2007)

Extract

This book is essential language-agnostic source to make your TDD delivering principal values: maintainable test code, joyful SUT refactorings, and zero product defects.

Contents

Summary
Concepts
- Goals of Test Automation
- Testing Philosophy
- Principles of Test Automation
Practice
- Test Smells
- Test Automation Strategy
- xUnit Basics
- Test Fixtures
- Result Verification
- Test Doubles
- Test Organization
- Testing with Databases
  - Issues with Testing with Databases
  - Testing without Databases
  - Testing the Database
  - Database Patterns
- A Roadmap to Effective Test Automation
  - Test Automation Difficulty
  - Roadmap to Highly Maintainable Automated Tests
- Remaining Patterns

Summary

While TDD by Example is more conceptual, practically demonstrating only TDD cycle, this one presents a much wider and very practical body of knowledge a software engineer must not miss.

[INFO] [xUnit](https://en.wikipedia.org/wiki/XUnit) is the family of unit testing frameworks implementing unified specific approaches and test code patternsThe family includes test frameworks for Java, C#,, JavaScript, PHP to name a few.

Despite seemingly heavy, The book is effectively organized and is a pleasure to absorb using my reviewSkim the diagrams and maps, take 1-2 techniques you like most and start applyingWhen hungry again return for moreWith time the book becomes a good foundational reference on testing.

The review combines "Part INarratives" and "Part IIIPatterns" into a single space as they discuss the same at different level on granularityPart I introduces concepts, Part III provides implementation patternsOn top the review moves the more broad concepts (goals, philosophy and principles) up.

Concepts

Goals of Test Automation

Tests should (p. 84):

Help us to improve quality and understand the SUT.
Reduce (and not introduce) risk.
Be easy to run, easy to write and maintain.
Require minimal maintenance as the system evolves around them.

Testing Philosophy

(p. 94)

Write the tests first!
Tests are examples (of SUT usage)!
Usually write tests one at a time, but sometimes list all the tests one can think of as skeletons upfront.
Outside-in development helps clarify which tests are needed for the next layer inward.
Use primarily State Verification (p. 172, 525) but will resort to Behavior Verification (p. 531) when needed to get good code coverage.
Perform fixture design on a test-by-test basis.

Principles of Test Automation

(p. 102)

Write the Tests First
Design for Testability
Use the Front Door First
Communicate Intent
Don’t Modify the SUT
Keep Tests Independent
Isolate the SUT
Minimize Test Overlap
Minimize Untestable Code
Keep Test Logic Out of Production Code
Verify One Condition per Test
Test Concerns Separately
Ensure Commensurate Effort and Responsibility

Practice

Test Smells

continue at the original [review]

How I Started Writing Unit Tests for Vue Components

Sun, 30 Mar 2025 02:37:53 +0000

At some point, every frontend developer realizes that it would be great to somehow verify that their code is working as expected. For me, this moment came after a painful migration from Vue 2 to Vue 3, with tons of bugs and defects. It left me with yet another strand of gray hair, and I wasn’t the only one suffering.

My project and technology stack

The current project I’m working on is a classic CRM, full of forms upon forms, list rendering, modals, and constant data transformation. The technology stack includes Vue 3, Pinia, Vite, and ElementPlus, which allows for fast and flexible interface development.

Why unit tests?

After reading up on the theory behind pyramids and testing cups, I concluded that it’s easier to gradually add “unit” tests for new components and features, as well as cover any bugs with tests.

Just a quick note on the testing pyramid. This concept, introduced by Martin Fowler, helps organize tests in a project. It involves three levels of testing:

Unit Tests: the most basic level of testing, which checks individual modules or functions. Unit tests are fast, easy to set up
and ensure that components work correctly in isolation.
Integration Tests: test the interaction between multiple components or modules, like how components work together on a page.
They are more complex and slower, but provide an understanding of the
correctness of the integrations.
E2E tests (End-to-End Tests): test the entire application, simulating real user actions. E2E tests are slower and require
complex infrastructure but ensure that the app works as a whole.

The word "unit" is in quotes here because, when testing components in a framework, there’s a nuance: testing components isn’t always about isolating them completely.

Ideally, unit tests check isolated functions, (like the famous SUM () function), but in reality, we cannot entirely "mock" the framework. So, tests for Vue components are technically integration tests. However, for simplicity, the community continues to call them “unit tests” and I’ll stick with that terminology.

Testing options and my choice

Of course, there were other options. For example, I considered E2E testing with Playwright, which runs tests in real browsers simulating user actions. While Playwright is a powerful tool,I faced several infrastructure difficulties, which I’ll discuss later in the article.

Spoiler: the backend wasn't ready for this, and realistically, E2E tests should be written under the guidance of QA engineers - they are experts at breaking systems.

Ultimately, I decided to go with Vitest and Vue Test Utils as the main tools for testing. Vitest, as a test runner, was ideal, since Vite was already installed in the project, and Vue Test Utils provided all the necessary tools for mounting and modifying Vue components.

Why Vue Test Utils and not Testing Library? First, Vue Text Urils is recommended by the Vue community (Testing Library was a bit late in supporting Vue 3). Second, I follow "London School" of testing, where we mock everything around our component to keep tests as fair isolated as possible. In addition, the Testing Library is built on top of VTU, and I wanted fewer dependencies.

Installing and setting up

To get started, we need to install and configure Vitest and Vue test utils.

npm i -D vitest @vue/test-utils

Since our tests will run in a Node.js environment, we need DOM implementers. Vitest recommends either happy-dom or jsdom.

I chose jsdom because it’s more popular and faster, though happy-dom is an option as well as you can switch quickly.

npm i jsdom -D

Configuring the testing environment

Let's add the necessary configuration to vite.config.js.

defineConfig({
...
test: {
environment: 'jsdom',
deps: {
  inline: ['element-plus'], // optional field
},
},
})

Since Pinia is in the stack, we can either use a real store or a test store for testing. I opted for a test store, as it’s easier to mutate directly during tests.

npm i -D @pinia/testing

What and how to test?

Let's take a component with a button and a modal as an example.

Component diagram and description

Here’s the basic flow:

There is a button (which is enabled if the user has permission).
When clicked, it opens a form in a modal window (a separate
component).
When the form is filled and the "Add" button is clicked, a request is
sent to the server.
After a successful response, an event is emitted to indicate that the
document has been added.

Component code:

<template>
 <div>
   <button :disabled="!isAddDocumentAvailable" class="button button--primary" @click="addIncomingMail">Add incoming correspondence</button>
   <popup drawer :is-form-open="isFormOpen" @closed="closeForm">
     <add-incoming-mail-modal :lawsuit-id="lawsuitId" @closeForm="closeForm" @mail-added="onMailChanged" >
   </popup>
 </div>
</template>

<script setup >
import { ref } from 'vue';
import AddIncomingMailModal from '@/.../AddIncomingMailModal.vue';
const isFormOpen = ref(false);

const emits = defineEmits(['mail-added']);
defineProps({
 lawsuitId: {
   type: Number,
   required: true,
 },
});

function addIncomingMail() {
 isFormOpen.value = true;
}

function closeForm() {
 isFormOpen.value = false;
}
function onMailChanged() {
 emits('mail-added');
}
const isAddDocumentAvailable = computed(() => {
 return checkAvailabilityByClaim(...);
});
</script>

A bit of theory.

To start, we need to decide what should be tested. The general advice is to follow the user's behavior and avoid focusing on implementation details, which makes sense. Essentially, we’ll treat the component as a black box: changing (preparing) its input data and testing the output.

Note: if the component has a complex function with heavy calculations, it should ideally be extracted and tested separately as a traditional unit test.

Mocks and stubs play a key role in isolating tests. Mocks replace real dependencies, while stubs simplify interaction with external systems (API, for example). The main rule is not to mock everything: only mock what affects the functionality being tested. This reduces test dependence on the mock.

Input data includes properties, components, dependency injections, external stores, and slots. For a fair test, we should replace real components, stores, and DIs with stubs. This minimizes the risk of false positives.

Output: we should test the resulting HTMLcheck API calls (which should also be stubbed to avoid affecting the backend), and verify that events are emitted and handled correctly outside the component.

Let's move on to writing the test. First, we need to define what we are testing (as they say, "draw a circle").

describe('Adding incoming correspondence - AddIncomingMail', () => {

 it.todo('The "Add incoming correspondence" button is active if the user has rights', async () => {});

 it.todo('By clicking on the "Add incoming correspondence" button, a modal window for adding a new document opens', async () => {});

 it.todo('When adding incoming correspondence, we generate an event outside the component', async () => {});
});

Notice how these test descriptions serve as self-documenting code — in theory.

I prefer placing tests as close to the components as possible. This approach seems better suited for understanding how the component works.

In general, we draw another circle, add details, and - we have a test.

import { getButtonByText } from '@/mocks/helpersForTesting/searchElements/index.js';
import { mount } from '@vue/test-utils';
import AddIncomingMail from '@/components/AddIncomingMail.vue';
import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest';
import { createTestingPinia } from '@pinia/testing';

let wrapper; // storing a component instance

beforeEach(() => { // before each test we mount the component with the initial settings
 wrapper = mount(AddIncomingMail, {
   global: {
plugins:[    
createTestingPinia({ // Create a test instance of Pinia
         createSpy: vi.fn,
         stubActions: false,
         initialState: {
           user: {
             state: {
               claims: [1,2],
             },
           },
         },
       }),]
     stubs: { // Since this is unit testing, we replace all child components with stubs
       AddIncomingMailModal: {
         name: 'AddIncomingMailModal',
         emits: ['mail-added'],
         template: '<div><h2 >Add correspondence</h2></div>',
       },
       popup: {
         props: { isFormOpen: false },
         template: '<div v-if="isFormOpen"><slot></div>',
       },
     },
   },
   props: {
     lawsuitId: 15,
   },
 });
});

afterEach(() => { // After each test, we reset the stubs and destroy the instance
 wrapper.unmount();
 vi.resetAllMocks();
});

describe('Adding incoming correspondence - AddIncomingMail', () => {
 it('The "Add incoming correspondence" button is active if the user has rights', async () => {
   const button = getButtonByText({ wrapper, buttonText: 'Add incoming correspondence' }); // Made a helper for quick search of buttons

expect(button.element.disabled).toBe(false);
});

 it('By clicking on the "Add incoming correspondence" button, a modal window for adding a new document opens', async () => {
   const button = getButtonByText({ wrapper, buttonText: 'Add incoming correspondence' });

   await button.trigger('click');
   await wrapper.vm.$nextTick(); //Since Vue makes changes asynchronously, it is important to wait

   expect(wrapper.text()).contain('Add correspondence');
 });

it('When adding incoming correspondence, we generate an event outside the component', async () => {
   const button = getButtonByText({ wrapper, buttonText: 'Add incoming correspondence' });
   await button.trigger('click');
   await wrapper.vm.$nextTick();
   const modalStub = wrapper.findComponent({ name: 'AddIncomingMailModal' });

   modalStub.vm.$emit('mail-added');
   expect(wrapper.emitted()).toHaveProperty('mail-added');
 });
});

I would like to draw your attention to how element searching occurs. You should try to search for elements the way a user would search. A less recommended, but more popular approach is using data-testid=”foo”.

Note: Settings like the ones below:

afterEach(() => { // After each test, we reset the stubs and destroy the instance
  wrapper.unmount();
  vi.resetAllMocks();
});

can be moved to external files and connected in the vite.config.js settings as a global setting:

// vite.config.js
export default defineConfig({
  test: {
    // ...
    setupFiles: ['path to your file'],
    // ...
  },
});

Problem with unit tests

Ultimately, unit tests help establish a contract between components. However, there's a downside: if we change the modal’s code, for example, its emitted events, the test for AddIncomingMail won’t fail.

This is where integration tests (as mentioned earlier) come in, testing larger sections of the app.

I haven’t fully implemented those tests yet, as I’m still thinking about the infrastructure and mocks (particularly for server requests), through a conditional msw. However, there is a problem with maintaining the relevance of mocked responses (fixtures). Ideally, I'd like to use “Vitest browser mode” or “Playwright CT”, but these tools are still in their infancy.

Start testing your code early and don’t treat testing as something separate from development. Yes, at first it will be tough, and yes, it will continue to be tough, but soon enough, you’ll just get used to it.

Author: Dmitry Simonov, Frontend Developer at ByteMinds

Testing in Python: Writing Test Cases with unittest

Mon, 08 Apr 2024 21:17:24 +0000

After developing the software application, you want to check and verify the functionality of the software before releasing it onto the market. You likely want to ensure its functionality based on the prescribed requirements. So, for that, a software testing framework is used here. Developers create multiple test cases to perform software testing. So, in this article, we will cover the basics of test cases, their purpose, and characteristics along with the techniques of writing good test cases. Also, the ways of organizing and managing the test cases effectively.

Importance of Test Case and unittest Module

Now you are wondering about test cases. In simple terms, it's like a blueprint to ensure the robustness and performance of the software application against diverse scenarios. It is important to write test cases because testing is nothing without it, and they act as an overseer for software quality. It provides a tester, the structured approach, to verify the software and make it error-prone before delivering it to the user. All this can be achieved by using the Python module i.e. unittest.

Understanding Test Cases

1. Definition of Test Cases

A test case is a set of conditions or actions used for performing software testing on the application to verify the expected functionality or features. It helps the testing team verify every part of the software to find bugs or errors beforehand. The test cases are written based on software requirements.

2. Purpose of Test Cases in Software Development

Testing needs to be performed with proper planning, otherwise the tester or the user will not be satisfied with the software working. In test cases, testers design and document all conditions in such a way that it covers all the scenarios before the testing phase. It has several key principles, such as detecting errors at early stages, helping to mitigate the risk of occurrence in the future, and the detailed coverage for testing the software in different environments.

3. Characteristics of Good Test Cases

Clarity: The tester should write test cases in an understandable language, providing clarity to all the stakeholders involved in the testing. They should be clear enough to understand each pre-step to perform the testing.
Completeness: The tester should write test cases concisely and in a structured way that covers all the scenarios that software can undergo. They should cover all the expected requirements and aspects of the software application.
Independence: Each test case should be independent of the other, which means the result of one test case does not affect the outcome of the other. This way, you can better facilitate the bugs in isolation.
Reliability: Each test case should be reliable in verifying software functionalities because it provides extensive coverage for testing the software in diverse circumstances. That makes the test cases more reliable than the unplanned and manual testing.

4. Benefits of Writing Test Cases

Bug Detection: Test cases help us to identify the bugs and defects at the early stages of development. While executing the test cases, the tester can easily identify the loopholes or areas that need to be changed or updated. It ensures the system needs to be tested against multiple input values to get similar outcomes and track the bugs.
Regression Testing: Changes are inevitable and need to be handled carefully without impacting the other functionality. Therefore, detailed test cases allow the software tester to verify the new functionality and assess its impact on other functionalities by the changes.
Documentation: The tester documents the test cases concisely and in a structured manner, having a specific pattern that includes the pre and post-conditions and all other key points needed while testing. That helps the tester to keep a track record of each bug and error to show the software quality to the user.
Collaboration: It also encourages collaboration between the team members while writing and executing the test cases. Not only that, but you can get early feedback from the user by collaborating with them.

Note: Many developers prefer to use an automated CI/CD pipeline to catch the changes done in the application. It will help you in advance with regression testing.

Introduction to the unittest Module

Overview of the unittest Module in Python

unittest is the automated testing library, introduced by Python for performing unit testing. It is the part of Python standard library that allows us to write and execute unit tests for our Python modules. Its working process is derived from OOP, having a set of classes and methods that provide us with the functionality to write tests and execute them.

Features of unittest

The unittest module offers developers many features that enable them to write robust, comprehensive, and maintainable test cases. The following key features are:

Test Fixture: In the unittest module, the test fixture represents the need to initialize and clean up the task before and after the test execution.
Test Suite: It consists of the collection of test cases having similar tasks.
Test Discovery: It is used for finding the test cases within the directory without manual intervention and running them.
Test case: It consists of a set of conditions needed to check and verify the working of software functionalities.
Test Runner: It is a final component used for running and executing the test and displaying the outcome to the user.

History and Evolution of unittest

The unittest testing module is part of Python standard library. Its idea is from JUnit, which is a Java testing framework. As we know, the JUnit testing module is designed to provide an automated way of testing the individual modules of the Java application. Therefore, that idea is adapted by Python, providing the PyUnit framework which was later evolved by Python 2.7 and added in the standard library as an unittest module for the Python developer.

Advantages of Using unittest for Writing Test Cases

Now that we have seen the history and features of the unittest module, let's see some advantages for writing better test cases.

Firstly, it is a built-in library that contains all the functions and testing methods, so there is no need for separate installation.
The developers familiar with JUnit will easily understand its working, as it is based on the JUnit framework.
It offers a more concise and readable structured manner compared to manual testing, making test cases easier to write and understand.
The unittest module offers simplicity and compatibility, especially with smaller projects or projects having strict and limited environments.

Getting Started with Writing Test Cases

Let's understand the writing and execution of a test case using the unittest module of Python with an example:

1. Setting up a Test Case

Suppose we create a class called employee, having all employee details. Now, we want to test the email pattern and payment increment method of each employee; for that, we need to write the test methods for checking emails as well as for payment of each employee. Let's start by writing the source code:

class Employee: #employee class
    increment_amt = 1.05 #variable with increment value

    def __init__(self, name, pay): #function for taking values 
        self.name = name
        self.pay = pay
    
    @property
    def email(self): #email function 
        return '{}@gmail.com'.format(self.name)
    
    def increment(self): #function of incremeting the payment
        self.pay = int(self.pay * self.increment_amt)

First, create a directory for your project and navigate to it. Then create the new file with the name, test_employee.py. So, your directory structure will look something like this:

Then, import the unittest library into the test_employee.py file. Also, import the Employee class from the src directory, where the source code of emplyess.py is provided.

import unittest #importing the module
from src_code.employee import Employee

2. Anatomy of a Test Case Class

After that, declare the test class derived from the base class of the unittest module. Then, define the test fixture methods i.e. setup() and teardown() methods containing the code required before and after the execution of test methods.

class Testing(unittest.TestCase): #used the base class for creating testing subclass 
    def setUp(self): #setup the resource before each execution 
        self.emp1 = Employee('john', 50000) 
        self.emp2 = Employee('stephen', 60000) 

    def tearDown(self): #deleting the employee 
        del self.emp1

3. Writing Test Methods

Naming Conventions

The Python unittest module defines the naming convention to start the method name with the prefix test_ so that the unittest module can easily identify the test methods upon execution.

Tip: Always try to give meaningful names to the testing methods that describe the method behavior for clarity.

Test Method Structure

The structure of the test method consists of AAA (Arrange, Act, and Assert). In arrange, you provide the setup values which we have done in the setup() function. The act includes the input and output values and invokes the function. Therefore, writing the test methods consists of the input values, the output values, and the assert condition to verify the outcome.

def test_email(self):  #function names start from test_ prefix
    self.assertEqual(self.emp1.email, '*Emails are not allowed*')  #checks email of employee 1
    self.assertEqual(self.emp2.email, '*Emails are not allowed*')  #check email of employee 2
    
def test_increment(self): #function names start from test_ prefix
    self.emp1.increment()  #call the increment function
    self.emp2.increment() 
    self.assertEqual(self.emp1.pay, 52500) #verfiy the increment value
    self.assertEqual(self.emp2.pay, 63000)

4. Running the Test Case

For running the test case, the test runner function is used at the end of the test_employee.py file.

Output

Organizing Test Cases

Test case management and organization play a crucial role in streamlining the testing process, enhancing productivity, and ensuring comprehensive test coverage. Well-structured test cases will help the QA team to test the specific functionality easily, track the record of test case results, and figure out the bugs promptly. If the test cases are unorganized, then it creates chaos between the team members, leading to inefficient and duplicate efforts.

1. Grouping Test Cases into Test Suites

In software testing, the test suite is the collection of test cases that belong to the same category such as functionalities, scenarios, and features. Each test suite works for a specific aspect. This will help the tester to categorize similar features and execute the multiple test cases parallel effectively.

2. Using test loaders to discover and load test cases

Test loader is one of the functions of the unittest module, used for dynamically loading the test cases from the test suite. An automated process of locating and executing the test cases reduces the need for manual intervention and the risk of human errors. You can use the unittest.TestLoader() function, to discover the test case.

import unittest #importing the module
from src_code.employee import Employee

class email_testing(unittest.TestCase): #testcase 1: for testing the email
    def test_email(self):
        self.emp1 = Employee('john', 50000)
        self.emp2 = Employee('stephen', 60000)
        self.assertEqual(self.emp1.email, '*Emails are not allowed*')
        self.assertEqual(self.emp2.email, '*Emails are not allowed*')

class increment_testing(unittest.TestCase): #testcase 2: for testing the payement increment
    def test_increment(self):
        self.emp1 = Employee('john', 50000)
        self.emp2 = Employee('stephen', 60000)
        self.emp1.increment()
        self.emp2.increment()
        self.assertEqual(self.emp1.pay, 52500)
        self.assertEqual(self.emp2.pay, 63000)

def create_test_suite(): #create suite 
    suite = unittest.TestSuite()
    suite.addTest(unittest.makeSuite(email_testing)) #add email testing testcase in the suite
    suite.addTest(unittest.makeSuite(increment_testing)) #add payment testing testcase in the suite
    return suite
        
if __name__ == '__main__': #used to class the main class of unittest
    loader = unittest.TestLoader()#deriving the loader from unittest module
    suite = create_test_suite()
    unittest.TextTestRunner().run(suite)

Output

3. Organizing Test Suites and Test Cases Using Modules and Classes

Organizing the test suite and test cases using modules and classes provides the structures and granular approach for testing the application. The modules define the test cases, which means each module has specific functionality. Whereas, the classes define the test suite, which contains the group of test cases having similar features and scenarios. This approach will help the developer enhance the readability of the code, and promote the reusability of the modules.

Tip: Try to follow a test-driven development approach, this will prepare you to write test cases before the actual development.

FAQs Q: How can I run a test file using the command prompt?
A: You can easily run the file in CMD by using this command "python -m unittest test_file.py". Q: If I dont use the prefix "test_" my method consider as test method?
A: No, the unittest module doesn't take the method as a testing method if the naming convention is not followed properly. Q: What is test coverage?
A: Test coverage is the technique that tells us how much application features and code are covered by test cases.

Wrapping Up

In conclusion, we learned that test cases are the essential building blocks of software testing. Most developers use test cases to verify the software application's robustness, system maintenance, and specific features based on the requirements given by the user. Additionally, it helps you evaluate the quality and reliability of your application. Whether you are working on an enterprise-level application or developing a small program, testing is important to ensure every feature works properly, even if it's a hectic process. However, all this becomes easy with the help of Python's built-in testing framework i.e. unittest. So, stay with me for the details of this module. I hope this guide is helpful for you. Happy Coding!

Reference

unittest Module
Test Case

Coder Legion - Recent posts tagged unittest

Refactoring Go API Unit Tests: Breaking Down the Testing Monolith

The Concept

The What

The Why

The How

1. Centralizing Mocks (mock.go)

2. Testing the Business Logic (*_service_test.go)

3. Testing the HTTP Transport Layer (*_handler_test.go)

The Trade-offs

In Layman's Terms

Conclusion

[BOOK REVIEW] Meszaros G., xUnit Test Patterns (2007)

Meszaros G., xUnit Test Patterns (2007)

Summary

Concepts

Goals of Test Automation

Testing Philosophy

Principles of Test Automation

Practice

Test Smells

How I Started Writing Unit Tests for Vue Components

My project and technology stack

Why unit tests?

Testing options and my choice

Installing and setting up

Configuring the testing environment

What and how to test?

Problem with unit tests

Testing in Python: Writing Test Cases with unittest

Importance of Test Case and unittest Module

Understanding Test Cases

1. Definition of Test Cases

2. Purpose of Test Cases in Software Development

3. Characteristics of Good Test Cases

4. Benefits of Writing Test Cases

Introduction to the unittest Module

Overview of the unittest Module in Python

Features of unittest

History and Evolution of unittest

Advantages of Using unittest for Writing Test Cases

Getting Started with Writing Test Cases

1. Setting up a Test Case

2. Anatomy of a Test Case Class

3. Writing Test Methods

Naming Conventions

Test Method Structure

4. Running the Test Case

Organizing Test Cases

1. Grouping Test Cases into Test Suites

2. Using test loaders to discover and load test cases

3. Organizing Test Suites and Test Cases Using Modules and Classes

Wrapping Up

Reference

1. Centralizing Mocks (`mock.go`)

2. Testing the Business Logic (`*_service_test.go`)

3. Testing the HTTP Transport Layer (`*_handler_test.go`)