Most Frequently asked unit-testing Interview Questions (2024)

Question: Can you explain the difference between a stub and a mock in unit testing?

Answer:

In unit testing, both stubs and mocks are used to replace dependencies of the unit under test with controlled, simplified versions that allow for isolated testing. However, there are key differences between these two concepts in terms of their purpose, usage, and behavior.

---

1. Definition

• Stub: A stub is a simplified implementation of a dependency that returns pre-defined values when certain methods are called. Stubs are used primarily to control the behavior of the dependency by providing specific return values. They do not verify how the dependency is used or what interactions occur between the unit under test and the dependency.

• Mock: A mock is a more sophisticated version of a stub, but it not only provides predefined responses but also verifies the interactions between the unit under test and the dependency. Mocks can check if specific methods were called on them, whether they were called with correct arguments, and how many times they were called. Mocks focus on behavior verification.

---

2. Purpose

• Stub:
  • Primary Purpose: Control the behavior of the dependency in a simple and deterministic way, usually by returning fixed values.
  • Focus: Ensuring the code under test behaves correctly given specific return values from the dependency.
• Mock:
  • Primary Purpose: Verify that the unit under test interacts with the dependency in the expected way, such as calling methods with the correct parameters, and checking the sequence and frequency of interactions.
  • Focus: Ensuring that the right methods were called, with the right arguments, the right number of times.

---

3. Behavior vs Interaction

• Stub:
  • A stub is concerned with providing behavior. It just returns a predefined result when a method is called, without inspecting or verifying how the method is used. It does not track or assert interactions.
• Mock:
  • A mock is concerned with verifying interactions. It not only returns predefined values but also tracks and asserts whether certain methods were called, whether they were called with the right arguments, and how many times they were called. Mocks focus on the behavior of the test, not just the return values.

---

4. Example: Stub vs Mock in Python

Let’s take a simple example where we have a PaymentService class that depends on a PaymentGateway:

Stub Example:

Here, we are just providing a predefined return value from the PaymentGateway.

class PaymentGateway:
    def process_payment(self, amount):
        return True  # Actual implementation would process payment

class PaymentService:
    def __init__(self, gateway):
        self.gateway = gateway
    
    def pay(self, amount):
        return self.gateway.process_payment(amount)

# Unit Test using a Stub
from unittest.mock import Mock

def test_payment_service():
    # Stub: Create a PaymentGateway mock that always returns True
    stub_gateway = Mock()
    stub_gateway.process_payment.return_value = True
    
    payment_service = PaymentService(stub_gateway)
    
    result = payment_service.pay(100)
    
    assert result == True  # We verify that the payment was successful

In this case, the stub ensures that process_payment() always returns True so that we can test the PaymentService without actually invoking the real PaymentGateway.

Mock Example:

In the mock version, we are not only controlling the behavior but also verifying that the process_payment() method is called with the correct argument.

from unittest.mock import Mock

def test_payment_service_with_mock():
    # Mock: Create a mock that verifies the interaction
    mock_gateway = Mock()
    
    payment_service = PaymentService(mock_gateway)
    
    payment_service.pay(100)
    
    # Verify that 'process_payment' was called with the argument 100
    mock_gateway.process_payment.assert_called_with(100)

In this case, the mock ensures that the process_payment() method was called with the argument 100, and this verifies the interaction between the PaymentService and PaymentGateway.

---

5. Key Differences

Feature	Stub	Mock
Purpose	Control the behavior (return values).	Verify interactions (method calls).
Interaction Tracking	No, just return values.	Yes, tracks and verifies interactions.
Behavior	Focused on return values.	Focused on method calls and their parameters.
Usage	Simplifies testing by controlling dependency behavior.	Ensures the unit under test interacts correctly with the dependency.
Framework Support	Usually simpler (e.g., unittest.mock provides basic stubbing).	More advanced, used in testing frameworks like Mockito, Moq.
Example Use Case	Returning a fake response for a complex external API.	Verifying that the correct method was called on a service with the correct parameters.

---

6. When to Use Stubs vs Mocks

• Use a Stub when:

  • You need to isolate your test from the actual behavior of a dependency.
  • You want to control the behavior of the dependency (e.g., return a fixed value, simulate certain scenarios).
  • You are not interested in verifying how the unit interacts with the dependency, only that it works with the provided return values.

• Use a Mock when:

  • You need to verify that the unit under test interacts with its dependency in the correct way (e.g., correct method calls, arguments, number of calls).
  • You care about how the code interacts with dependencies, not just the return values.
  • You need to test if the unit under test is calling methods on its dependencies with the expected parameters.

---

Conclusion:

• Stubs are focused on controlling the behavior of a dependency by providing specific return values, while Mocks are used to verify the interactions between the unit under test and its dependencies.
• Stubs are useful for simplifying the environment during testing, and mocks are essential for ensuring that the code interacts with dependencies in the correct manner.

Both stubs and mocks are vital in unit testing, and understanding their roles allows you to create more effective and reliable tests.

Question: How do you ensure that your unit tests are isolated and do not rely on external systems (e.g., databases, file systems)?

Answer:

Ensuring that unit tests are isolated and do not rely on external systems, such as databases or file systems, is a crucial aspect of writing effective and reliable tests. Unit tests should ideally focus on testing the logic of the code without dependencies on external systems, which can introduce variability, slow down the tests, and make them unreliable. Below are several strategies to achieve test isolation and eliminate reliance on external systems:

---

1. Use of Mocks and Stubs

• Mocks and stubs are essential tools for isolating unit tests from external systems. Mocks and stubs replace real system components (like databases, APIs, or file systems) with controlled, predefined responses.
• Mocking frameworks (such as unittest.mock in Python, Mockito in Java, or MoQ in C#) allow you to simulate the behavior of external systems, like returning a specific value when a method is called or tracking method invocations without actually connecting to the external system.

Example (Python using unittest.mock):

from unittest.mock import Mock

# Imagine we have a function that interacts with a database
def get_user_from_db(user_id, db_connection):
    return db_connection.get_user(user_id)

def test_get_user_from_db():
    # Mock the database connection
    mock_db = Mock()
    mock_db.get_user.return_value = {"id": 1, "name": "Alice"}
    
    # Test the function with the mock
    user = get_user_from_db(1, mock_db)
    
    # Verify that the mock was called
    mock_db.get_user.assert_called_once_with(1)
    assert user == {"id": 1, "name": "Alice"}

In this example, the test does not interact with an actual database; instead, it uses a mock to simulate the database’s behavior.

---

2. Dependency Injection

• Dependency Injection (DI) is a technique that allows you to inject dependencies into classes or functions instead of hard-coding them. This makes it easier to swap real dependencies (e.g., database connections, file systems) with mocks or stubs during testing.
• By injecting dependencies, you can replace real components with mock objects or in-memory implementations that provide the same interface but don’t rely on external systems.

Example (Python with DI):

class Database:
    def get_user(self, user_id):
        # Simulate database access
        pass

class UserService:
    def __init__(self, db: Database):
        self.db = db

    def get_user(self, user_id):
        return self.db.get_user(user_id)

def test_get_user_service():
    # Mocking the Database dependency
    mock_db = Mock()
    mock_db.get_user.return_value = {"id": 1, "name": "Alice"}

    user_service = UserService(mock_db)
    user = user_service.get_user(1)

    assert user == {"id": 1, "name": "Alice"}

In this example, the UserService class takes a Database object as a dependency. During the test, you inject a mock Database object instead of connecting to a real database.

---

3. Use In-Memory Implementations

• For some cases, you might still need a database or file system but want to avoid external dependencies. In such cases, using in-memory databases or in-memory file systems can be helpful.
• For example, libraries like SQLite (in-memory mode) or H2 (in-memory database) allow you to simulate a database without needing a real database server.
• Similarly, libraries like pyfakefs in Python simulate a file system in memory, enabling you to test file operations without touching the actual file system.

Example (In-memory database with SQLite in Python):

import sqlite3
import unittest

class TestDatabase(unittest.TestCase):
    def setUp(self):
        # Create an in-memory database for testing
        self.conn = sqlite3.connect(':memory:')
        self.cursor = self.conn.cursor()
        self.cursor.execute("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)")

    def test_insert_user(self):
        self.cursor.execute("INSERT INTO users (name) VALUES ('Alice')")
        self.conn.commit()

        self.cursor.execute("SELECT name FROM users WHERE id = 1")
        user = self.cursor.fetchone()
        assert user[0] == 'Alice'

    def tearDown(self):
        self.conn.close()

In this example, SQLite’s in-memory mode is used to simulate database interaction, allowing for isolated tests without any real database setup.

---

4. Avoid Real External Dependencies (e.g., API calls, file writes)

• Avoid making actual API calls or writing to file systems during unit tests. These operations introduce dependencies on external systems, increase test runtime, and can result in inconsistent or flaky tests.
• Use mocking libraries to simulate API responses, as well as file system operations like file reads and writes.

Example (Mocking an API call using requests-mock in Python):

import requests
import requests_mock

def fetch_data_from_api(url):
    response = requests.get(url)
    return response.json()

def test_fetch_data_from_api():
    with requests_mock.Mocker() as mock:
        mock.get('http://example.com/api', json={"key": "value"})
        data = fetch_data_from_api('http://example.com/api')
        assert data == {"key": "value"}

This test uses requests_mock to simulate an API response without making a real HTTP request.

---

5. Use Fixtures and Setup/TearDown Methods

• You can use test fixtures, setup, and teardown methods to prepare your testing environment and clean up afterward. These methods ensure that your tests are isolated by providing a clean state before and after each test.
• The setup method can be used to initialize in-memory databases, mock objects, or any other dependencies, and the teardown method can ensure that no state persists between tests.

Example (Python with unittest):

import unittest

class TestService(unittest.TestCase):
    def setUp(self):
        # Set up mocks or in-memory services
        self.mock_service = Mock()
        self.mock_service.some_method.return_value = "Mocked Value"

    def test_method(self):
        result = self.mock_service.some_method()
        self.assertEqual(result, "Mocked Value")

    def tearDown(self):
        # Clean up any state, if needed
        pass

---

6. Environment Isolation

• Ensure that tests are environmentally isolated by avoiding any interactions with external systems like production databases, file systems, or third-party APIs.
• Use tools like Docker to create isolated containers for running integration tests that may depend on external services, while keeping unit tests purely isolated.

---

7. Use of Continuous Integration (CI) and Test Automation

• Use a CI pipeline to automatically run unit tests in isolated environments every time you make changes to the codebase. This ensures that tests do not accidentally rely on external systems during local development.

---

Conclusion:

To ensure that unit tests are isolated and do not rely on external systems:

1. Use mocks and stubs to replace external dependencies with controlled, simplified behavior.
2. Inject dependencies into your code to facilitate testing with mocks and stubs.
3. Use in-memory databases or in-memory file systems to simulate external systems.
4. Avoid making real API calls or writing to the file system in unit tests.
5. Use test fixtures and setup/teardown methods to manage test environments.
6. Ensure tests are environmentally isolated using tools like Docker for complex integration tests.
7. Leverage CI pipelines to automate and ensure test isolation in a consistent environment.

By following these practices, you can ensure that your unit tests remain fast, reliable, and isolated from external dependencies.

Question: What is code coverage, and how do you measure it in unit testing?

Answer:

Code coverage is a metric used to determine the percentage of code that is exercised (i.e., executed) during the testing process. It helps identify which parts of your codebase are being tested and which parts might require additional tests. High code coverage generally indicates that a larger portion of the code has been tested, leading to more robust and reliable software.

1. Types of Code Coverage

There are several different types of code coverage that provide insights into different aspects of testing:

a. Statement Coverage

• Definition: Measures the percentage of statements (or lines) in the code that have been executed at least once during testing.
• Goal: Ensure that every line of code is tested at least once.
• Limitations: Does not account for whether branches or paths in the code are tested.

b. Branch Coverage

• Definition: Measures whether each branch (decision point, such as if statements or loops) in the code has been executed in both possible directions (true and false branches).
• Goal: Ensure that all possible outcomes of decisions (conditional statements) are tested.
• Limitations: While better than statement coverage, it still doesn’t guarantee that all paths are tested.

c. Path Coverage

• Definition: Measures the percentage of all possible execution paths through the code that have been tested. A path is a unique sequence of statements, including decisions and loops.
• Goal: Ensure that all possible execution routes through the program have been tested.
• Limitations: This is more exhaustive but can be difficult to achieve for complex programs due to the combinatorial explosion of possible paths.

d. Function Coverage

• Definition: Measures the percentage of functions or methods that have been called during testing.
• Goal: Ensure that all functions in the code are tested at least once.
• Limitations: Doesn’t necessarily account for the logic inside the functions, just whether they were called.

e. Condition Coverage

• Definition: Measures whether each individual condition (e.g., each boolean expression) in a decision statement evaluates both to True and False.
• Goal: Ensure all individual conditions within a decision point are tested.
• Limitations: May require more tests to achieve full condition coverage in complex decision statements.

---

2. Why is Code Coverage Important?

• Identifies untested code: Code coverage tools highlight the portions of the code that have not been tested, helping you target areas that might need more thorough testing.
• Improves software quality: A high level of code coverage generally indicates that your software has been more thoroughly tested, reducing the risk of bugs and regressions.
• Boosts confidence in changes: If you make a change to the codebase, having high code coverage gives you confidence that existing functionality will continue to work as expected.
• Helps in refactoring: High code coverage ensures that tests are in place to catch regressions when refactoring code.

---

3. How to Measure Code Coverage in Unit Testing

Code coverage is typically measured using code coverage tools that integrate with your testing framework. These tools track which parts of the code are executed during tests and generate reports that show coverage statistics.

Here’s how you can measure code coverage:

Step 1: Choose a Code Coverage Tool

There are several tools available for different programming languages and testing frameworks. Some popular ones include:

• Python: coverage.py
• Java: JaCoCo, Cobertura
• JavaScript: Istanbul, nyc
• C#/.NET: Visual Studio Code Coverage, Coverlet
• Ruby: SimpleCov

Step 2: Run Unit Tests with Coverage Tracking

Once you’ve selected a tool, you run your unit tests with code coverage tracking enabled. The tool will measure which lines, branches, and functions are executed during the test run.

Example (Python using coverage.py):

# Install coverage tool
pip install coverage

# Run tests with coverage measurement
coverage run -m unittest discover

# Generate a coverage report
coverage report

# Optionally, generate an HTML report
coverage html

Example (Java using JaCoCo with Maven):

# Add JaCoCo plugin to your Maven build
mvn clean test jacoco:report

Step 3: View the Code Coverage Report

After running your tests, the coverage tool will generate a report that shows the percentage of the codebase covered by your tests. The report can be in various formats, such as:

• Text report: A simple command-line output showing percentages of coverage.
• HTML report: An interactive, graphical interface that visually highlights covered and uncovered code lines.
• XML report: Can be used for continuous integration pipelines or further analysis.

Example (Coverage Report - Python):

$ coverage report
Name               Stmts   Miss  Cover   Missing
------------------------------------------------
my_module.py         100     10    90%     25-30, 45-55
test_my_module.py     50      5    90%     12-15
------------------------------------------------
TOTAL                150     15    90%

This example shows that 90% of the code has been covered, with specific lines (25-30, 45-55) uncovered.

Step 4: Interpret the Results

A code coverage report will show you the percentage of code covered, the uncovered lines or branches, and help you identify areas that need more testing.

You can set a coverage threshold (e.g., 80% coverage) to ensure that tests cover enough of the code. If the coverage falls below this threshold, the test suite may be flagged as incomplete or failing.

---

4. Best Practices for Code Coverage

1. Aim for high coverage, but not 100%:

   • While it’s important to have high code coverage, achieving 100% coverage is often impractical and unnecessary. Focus on covering the critical paths, business logic, and edge cases rather than achieving perfection.

2. Focus on meaningful coverage:

   • Instead of aiming for a high number, aim for covering important parts of the code. For example, covering business-critical modules, decision points, and edge cases is more valuable than covering trivial getters and setters.

3. Test the boundaries:

   • Ensure that your tests cover edge cases and boundary conditions. High code coverage does not necessarily mean that your tests cover all potential issues, so be mindful of edge case testing.

4. Use code coverage as a guide:

   • Use the code coverage report to identify untested or under-tested areas, but don’t treat it as the sole indicator of test quality. A low coverage percentage doesn’t always mean bad tests, and a high percentage doesn’t always mean good tests.

5. Integrate code coverage into CI/CD pipelines:

   • Integrate code coverage checks into your CI/CD pipeline to ensure that new code doesn’t reduce coverage or break existing tests.

6. Monitor over time:

   • Track code coverage over time to ensure that it is improving, rather than decreasing, as new features and refactoring are introduced.

---

5. Limitations of Code Coverage

• Does not guarantee bug-free code: High code coverage does not necessarily mean the code is free of bugs. It’s possible to have high coverage and still miss certain edge cases or faulty logic.
• Can encourage testing of trivial code: A focus on code coverage can sometimes lead to writing tests for trivial code (like getters/setters), which may not add significant value to the overall testing effort.
• Misses non-functional aspects: Code coverage tools measure only the execution of code but don’t check for performance, security, or usability issues.

---

Conclusion:

Code coverage is a vital metric in unit testing, providing insight into the portions of your code that have been exercised by tests. It helps ensure that critical parts of the application are thoroughly tested, but it is not the only indicator of test quality. By using code coverage tools like coverage.py, JaCoCo, or Istanbul, you can measure the effectiveness of your tests and identify areas that may need more attention. However, always combine code coverage with other testing practices (like edge case testing, integration testing, and manual testing) for the best results.

Question: How do you handle exceptions in unit tests?

Answer:

Handling exceptions in unit tests is crucial to ensure that your code behaves as expected in exceptional or error scenarios. Unit tests not only verify that your code works as expected under normal conditions, but also ensure that it handles edge cases and error conditions gracefully.

Here’s how to handle exceptions in unit tests:

1. Testing if an Exception is Raised

When you expect a function to raise an exception under certain conditions, you need to test that the exception is properly raised. Different testing frameworks provide mechanisms for this.

In Python (using unittest)

Python’s unittest framework provides an assertRaises method to check that an exception is raised.

Example:

import unittest

def divide(a, b):
    if b == 0:
        raise ValueError("Cannot divide by zero")
    return a / b

class TestDivide(unittest.TestCase):
    def test_divide_by_zero(self):
        with self.assertRaises(ValueError):
            divide(10, 0)

Here, the assertRaises method ensures that the ValueError exception is raised when calling divide(10, 0).

In Java (using JUnit)

In JUnit, you can use the expected attribute of the @Test annotation to test for exceptions.

Example:

import org.junit.Test;

public class CalculatorTest {
    @Test(expected = ArithmeticException.class)
    public void testDivideByZero() {
        Calculator.divide(10, 0);
    }
}

This test will pass if the ArithmeticException is thrown during the execution of divide(10, 0).

In C# (using NUnit or MSTest)

In NUnit, you can use the Assert.Throws method to assert that an exception is thrown.

Example:

using NUnit.Framework;

[TestFixture]
public class CalculatorTests {
    [Test]
    public void TestDivideByZero() {
        Assert.Throws<DivideByZeroException>(() => Calculator.Divide(10, 0));
    }
}

In MSTest, you can use the ExpectedException attribute:

Example:

[TestMethod]
[ExpectedException(typeof(DivideByZeroException))]
public void TestDivideByZero() {
    Calculator.Divide(10, 0);
}

2. Testing Exception Messages

It’s often important to verify that the exception raised contains the correct message or is raised in the correct context. You can test the exception message to ensure that the error message is informative and accurate.

In Python (using unittest)

You can use the assertRaises method with a context manager to capture the exception and inspect its message.

Example:

import unittest

def divide(a, b):
    if b == 0:
        raise ValueError("Cannot divide by zero")
    return a / b

class TestDivide(unittest.TestCase):
    def test_divide_by_zero(self):
        with self.assertRaises(ValueError) as context:
            divide(10, 0)
        self.assertEqual(str(context.exception), "Cannot divide by zero")

In Java (using JUnit)

You can use try-catch blocks in your test methods to catch the exception and assert the message.

Example:

import org.junit.Test;
import static org.junit.Assert.*;

public class CalculatorTest {
    @Test
    public void testDivideByZero() {
        try {
            Calculator.divide(10, 0);
            fail("Expected exception not thrown");
        } catch (ArithmeticException e) {
            assertEquals("Cannot divide by zero", e.getMessage());
        }
    }
}

In C# (using NUnit or MSTest)

You can catch the exception in a try-catch block and check the exception message.

Example in NUnit:

using NUnit.Framework;

[TestFixture]
public class CalculatorTests {
    [Test]
    public void TestDivideByZero() {
        var ex = Assert.Throws<DivideByZeroException>(() => Calculator.Divide(10, 0));
        Assert.AreEqual("Cannot divide by zero", ex.Message);
    }
}

3. Testing Custom Exceptions

If your code throws custom exceptions, you should test that these exceptions are raised as expected and contain the correct information.

Example in Python:

class CustomError(Exception):
    pass

def raise_custom_error():
    raise CustomError("Custom error occurred")

class TestCustomError(unittest.TestCase):
    def test_custom_error(self):
        with self.assertRaises(CustomError) as context:
            raise_custom_error()
        self.assertEqual(str(context.exception), "Custom error occurred")

Example in Java:

public class CustomExceptionTest {
    @Test
    public void testCustomException() {
        try {
            throw new CustomException("This is a custom error");
        } catch (CustomException e) {
            assertEquals("This is a custom error", e.getMessage());
        }
    }
}

4. Testing Exception Handling Logic

You may want to test that your code correctly handles an exception, i.e., does it catch exceptions and proceed as intended? You can verify this by asserting that the exception is caught and the system behaves correctly afterward.

Example in Python:

def handle_error(a, b):
    try:
        return a / b
    except ZeroDivisionError:
        return "Error: Division by zero"

class TestErrorHandling(unittest.TestCase):
    def test_handle_zero_division(self):
        result = handle_error(10, 0)
        self.assertEqual(result, "Error: Division by zero")

5. Mocking Exceptions in Unit Tests

Sometimes, you need to mock a part of your system that throws an exception. This can be done using mocking frameworks, like unittest.mock in Python, Mockito in Java, or Moq in C#.

Example in Python:

from unittest import mock

def risky_function():
    raise ValueError("Something went wrong")

class TestMockingExceptions(unittest.TestCase):
    def test_mock_exception(self):
        with mock.patch('path.to.risky_function', side_effect=ValueError("Mocked exception")):
            with self.assertRaises(ValueError):
                risky_function()

6. Best Practices for Handling Exceptions in Unit Tests

• Test expected exceptions: Always test for exceptions that your code is expected to raise under specific conditions.
• Test the correctness of exception messages: Ensure the exception message is informative and helps diagnose issues.
• Ensure exceptions are handled appropriately: Test that your code handles exceptions properly, either by catching and handling them or by letting them propagate.
• Avoid overuse of exceptions in tests: Don’t write tests that only check for the presence of exceptions unless necessary, as this may obscure the logic or intention of the code.
• Test custom exception classes: Ensure that custom exceptions are being raised and handled properly, along with their specific messages and attributes.

Conclusion:

Handling exceptions in unit tests ensures that your code behaves as expected when encountering error conditions. By using built-in methods provided by testing frameworks (e.g., assertRaises, expected annotations), you can test that exceptions are raised correctly and contain the right information. It’s important to test not just for the presence of exceptions, but also for the correctness of exception messages and the system’s ability to handle these situations gracefully.

Read More

If you can’t get enough from this article, Aihirely has plenty more related information, such as unit-testing interview questions, unit-testing interview experiences, and details about various unit-testing job positions. Click here to check it out.