Why white-box testing examines code internals in Testing Fundamentals - Framework Benefits

Framework Mode - Why white-box testing examines code internals

Folder Structure for White-Box Testing Framework

white_box_testing_framework/
├── src/
│   ├── main_code/          # Application source code
│   └── test_code/          # White-box test code
│       ├── unit_tests/     # Unit tests for functions and methods
│       ├── integration_tests/ # Tests for combined modules
│       └── helpers/        # Test utilities and mocks
├── config/                 # Configuration files (environments, test settings)
├── reports/                # Test execution reports
└── docs/                   # Documentation about tests and code coverage

Test Framework Layers for White-Box Testing

• Source Code Layer: The actual code under test where logic and internals reside.
• Test Code Layer: Contains unit and integration tests that access internal functions, branches, and conditions.
• Helper Utilities: Tools for mocking, stubbing, and setting up test data to isolate code parts.
• Configuration Layer: Manages environment variables, test parameters, and runtime options.
• Reporting Layer: Collects and displays test results, code coverage, and logs.

Configuration Patterns for White-Box Testing

• Environment Setup: Use config files or environment variables to switch between dev, test, and production settings.
• Test Parameters: Define inputs and expected outputs for internal functions to cover all code paths.
• Mocking Dependencies: Configure mocks for external services or modules to isolate the code under test.
• Code Coverage Tools: Integrate coverage settings to measure which parts of the code internals are exercised.

Test Reporting and CI/CD Integration

• Detailed Reports: Show pass/fail status for each internal function and branch tested.
• Code Coverage Reports: Visualize which lines and branches of code were executed during tests.
• CI/CD Integration: Automatically run white-box tests on code commits and merges to catch internal errors early.
• Alerts and Logs: Notify developers of failures with stack traces and logs for debugging.

Best Practices for White-Box Testing Frameworks

• Test Internals Thoroughly: Write tests that cover all branches, conditions, and loops inside the code.
• Use Clear Naming: Name tests to reflect the internal logic or function they verify.
• Isolate Tests: Mock external dependencies to focus on internal code behavior.
• Maintain Code Coverage: Aim for high coverage but focus on meaningful tests, not just numbers.
• Keep Tests Maintainable: Organize tests logically and update them when code internals change.

Self-Check Question

In the folder structure shown, where would you add a new unit test for a private function inside a module?

Key Result

White-box testing frameworks focus on testing internal code logic through structured unit and integration tests with detailed coverage and reporting.

Practice

1. Why does white-box testing focus on examining the internal code of a program?

easy

A. To verify the program's performance under load

B. To check the program's user interface for usability

C. To test the program without knowing its internal workings

D. To understand the program's structure and test specific code paths

Solution

1. Step 1: Understand white-box testing purpose

   White-box testing involves looking inside the code to test its logic and paths.

2. Step 2: Compare options with testing goals

   Only To understand the program's structure and test specific code paths matches the goal of testing internal code structure and paths.

3. Final Answer:

   To understand the program's structure and test specific code paths -> Option D

4. Quick Check:

   White-box tests code internals = D [OK]

Hint: White-box tests code internals, not UI or performance [OK]

Common Mistakes:

• Confusing white-box with black-box testing
• Thinking white-box tests UI or performance
• Ignoring the code structure in white-box testing

2. Which of the following is the correct syntax to write a white-box test case in Python using the unittest framework?

easy

A. class TestFunction(unittest.TestCase):
def test_case(self):
self.assertEqual(function_to_test(), expected_value)

B. def test_function():
assert function_to_test() == expected_value

C. function test_function() {
expect(function_to_test()).toBe(expected_value);
}

D.
function_to_test() == expected_value

Solution

1. Step 1: Identify Python unittest syntax

   Python unittest requires a class inheriting unittest.TestCase and methods starting with test_.

2. Step 2: Match options to unittest style

   class TestFunction(unittest.TestCase): def test_case(self): self.assertEqual(function_to_test(), expected_value) correctly defines a test class and method using self.assertEqual.

3. Final Answer:

   class TestFunction(unittest.TestCase): def test_case(self): self.assertEqual(function_to_test(), expected_value) -> Option A

4. Quick Check:

   Python unittest uses classes and assertEqual [OK]

Hint: Python unittest tests use classes and assertEqual method [OK]

Common Mistakes:

• Using plain functions without unittest class
• Confusing JavaScript or XML syntax with Python
• Missing self parameter in test methods

3. Consider this Python function and its white-box test case:

def is_even(n):
    if n % 2 == 0:
        return True
    else:
        return False

# Test case
assert is_even(3) == False
assert is_even(4) == True

What is the result of running this test case?

medium

A. First assertion fails, second passes

B. Both assertions fail

C. Both assertions pass, test succeeds

D. Syntax error in test case

Solution

1. Step 1: Evaluate is_even(3)

   3 % 2 is 1, so function returns False, matching assert is_even(3) == False.

2. Step 2: Evaluate is_even(4)

   4 % 2 is 0, so function returns True, matching assert is_even(4) == True.

3. Final Answer:

   Both assertions pass, test succeeds -> Option C

4. Quick Check:

   3 odd = False, 4 even = True [OK]

Hint: Check function output matches assertion values exactly [OK]

Common Mistakes:

• Assuming 3 is even
• Confusing modulus operator result
• Thinking assert causes syntax error

4. A white-box test case for a function has this code:

def calculate_discount(price):
    if price > 100:
        return price * 0.9
    else:
        return price * 0.95

# Test
assert calculate_discount(100) == 90

What is the problem with this test?

medium

A. The test expects wrong discount for price 100

B. The function has a syntax error

C. The test should use assertEqual instead of assert

D. The function does not handle negative prices

Solution

1. Step 1: Analyze function logic for price 100

   Price 100 is not greater than 100, so else branch applies: 100 * 0.95 = 95.

2. Step 2: Compare test assertion value

   Test expects 90, but function returns 95, so assertion fails.

3. Final Answer:

   The test expects wrong discount for price 100 -> Option A

4. Quick Check:

   Price 100 gets 5% discount, test expects 10% [OK]

Hint: Check boundary conditions carefully in tests [OK]

Common Mistakes:

• Assuming price 100 triggers > 100 condition
• Thinking assert is invalid in Python
• Ignoring else branch logic

5. You want to write white-box tests to cover all branches of this function:

def classify_number(x):
    if x > 0:
        if x % 2 == 0:
            return 'Positive even'
        else:
            return 'Positive odd'
    elif x < 0:
        return 'Negative'
    else:
        return 'Zero'

Which set of test inputs covers all branches?

hard

A. [2, 4, 6]

B. [1, 2, 0, -1]

C. [0, -5]

D. [-1, 0, 1]

Solution

1. Step 1: Identify branches to cover

   Branches: x > 0 with even and odd, x < 0, and x == 0.

2. Step 2: Check test inputs for coverage

   Input 1 covers positive odd, 2 covers positive even, 0 covers zero, -1 covers negative.

3. Final Answer:

   [1, 2, 0, -1] -> Option B

4. Quick Check:

   All branches tested by these inputs [OK]

Hint: Test positive even, positive odd, zero, and negative separately [OK]

Common Mistakes:

• Missing positive odd or even cases
• Not testing zero case
• Assuming fewer inputs cover all branches