Code review as testing in Testing Fundamentals - Build an Automation Script

Review code for common bugs and style issues

Preconditions (2)

Step 1: Open the 'calculator.py' file

Step 2: Check for syntax errors such as missing colons or parentheses

Step 3: Look for logical errors like incorrect operator usage

Step 4: Verify that variable names are meaningful and consistent

Step 5: Ensure functions have clear and simple logic

Step 6: Check for missing error handling in functions

Step 7: Look for repeated code that can be simplified

Step 8: Verify that comments explain complex parts of the code

Step 9: Check that the code follows PEP 8 style guidelines

✅ Expected Result: All syntax errors, logical bugs, style issues, and missing error handling are identified and documented

Automation Requirements - pylint and unittest

Assertions Needed:

No syntax errors detected by pylint

Functions return expected results for given inputs

Code style conforms to PEP 8 standards

Best Practices:

Use static code analysis tools like pylint for style and syntax checks

Write unit tests to verify function logic

Use meaningful assertion messages

Keep tests small and focused

Run tests automatically after code changes

Automated Solution

Testing Fundamentals

import unittest
import subprocess

# Run pylint to check code style and syntax
result = subprocess.run(['pylint', 'calculator.py', '--disable=all', '--enable=syntax-error,style'], capture_output=True, text=True)

class TestCalculatorFunctions(unittest.TestCase):
    def test_add(self):
        from calculator import add
        self.assertEqual(add(2, 3), 5, 'Add function should return sum of two numbers')
        self.assertEqual(add(-1, 1), 0, 'Add function should handle negative numbers')

    def test_subtract(self):
        from calculator import subtract
        self.assertEqual(subtract(5, 3), 2, 'Subtract function should return difference')
        self.assertEqual(subtract(0, 0), 0, 'Subtract function should handle zero inputs')

if __name__ == '__main__':
    # Check pylint output for errors
    print('Pylint output:')
    print(result.stdout)
    assert 'syntax-error' not in result.stdout, 'Syntax errors found in code'
    assert 'style' not in result.stdout, 'Style issues found in code'

    # Run unit tests
    unittest.main()

This script first runs pylint on the calculator.py file to check for syntax errors and style issues. It captures the output and asserts that no syntax errors or style problems are present.

Then, it defines unit tests for two example functions: add and subtract. Each test checks that the function returns correct results for sample inputs, with clear assertion messages to explain failures.

Using unittest ensures that function logic is tested automatically. Running pylint helps catch style and syntax problems early. This combination mimics a code review by automatically checking common issues.

Common Mistakes - 3 Pitfalls

Ignoring pylint warnings and errors

Writing unit tests without assertions

Hardcoding test inputs without covering edge cases

Bonus Challenge

Now add data-driven testing with 3 different input sets for each function

Show Hint

Practice

1. What is the main purpose of code review in software testing?

easy

A. To find bugs and improve code quality before running the code

B. To write new features faster

C. To deploy code to production immediately

D. To replace automated testing completely

Solution

1. Step 1: Understand code review purpose

   Code review is done to check code manually for errors and improvements before execution.

2. Step 2: Compare options with purpose

   Only To find bugs and improve code quality before running the code matches the goal of finding bugs and improving quality before running code.

3. Final Answer:

   To find bugs and improve code quality before running the code -> Option A

4. Quick Check:

   Code review = find bugs early [OK]

Hint: Code review finds bugs before running code [OK]

Common Mistakes:

• Thinking code review replaces automated tests
• Believing code review speeds up deployment
• Confusing code review with coding new features

2. Which of the following is the correct way to give feedback during a code review?

easy

A. Provide clear, constructive comments with examples

B. Only comment if you find a syntax error

C. Ignore small mistakes to save time

D. Say 'This code is bad' without explanation

Solution

1. Step 1: Understand effective feedback

   Good feedback is clear, constructive, and helps improve code with examples.

2. Step 2: Evaluate options

   Provide clear, constructive comments with examples matches this approach; others are either rude, incomplete, or ignore issues.

3. Final Answer:

   Provide clear, constructive comments with examples -> Option A

4. Quick Check:

   Constructive feedback = clear + helpful [OK]

Hint: Be clear and helpful in feedback [OK]

Common Mistakes:

• Giving vague or rude comments
• Ignoring minor but important issues
• Only pointing out syntax errors

3. During a code review, you see this Python snippet:

def add_numbers(a, b):
    return a + b

result = add_numbers(2, '3')
print(result)

What will happen when this code runs?

medium

A. It will print 5

B. It will print 23

C. It will raise a TypeError

D. It will print null

Solution

1. Step 1: Analyze function call with mixed types

   The function adds an integer 2 and a string '3', which is invalid in Python.

2. Step 2: Understand Python behavior on adding int and str

   Python raises a TypeError when trying to add int and str directly.

3. Final Answer:

   It will raise a TypeError -> Option C

4. Quick Check:

   int + str = TypeError [OK]

Hint: Adding int and string causes TypeError in Python [OK]

Common Mistakes:

• Assuming Python converts string to int automatically
• Thinking it concatenates as strings
• Expecting numeric addition without error

4. You find this JavaScript code during review:

function multiply(x, y) {
  return x * y;
}

console.log(multiply(5));

What is the issue and how to fix it?

medium

A. multiply is missing one argument; fix by passing two arguments

B. multiply returns NaN; fix by setting default value for y

C. No issue; it prints 5

D. multiply throws error; fix by wrapping in try-catch

Solution

1. Step 1: Check function call with missing argument

   Calling multiply(5) passes only one argument; y is undefined.

2. Step 2: Understand JavaScript behavior multiplying number and undefined

   Multiplying number by undefined results in NaN (Not a Number).

3. Step 3: Fix by setting default value for y

   Use default parameter like function multiply(x, y = 1) to avoid NaN.

4. Final Answer:

   multiply returns NaN; fix by setting default value for y -> Option B

5. Quick Check:

   Missing arg causes NaN; default fixes [OK]

Hint: Missing JS args can cause NaN; use defaults [OK]

Common Mistakes:

• Assuming missing argument is zero
• Expecting error instead of NaN
• Ignoring default parameter usage

5. You review this Python code snippet:

data = [1, 2, 3, 4, 5]
result = {x: x*2 for x in data if x > 2}
result[3] = 10
print(result)

What is the final output and what does it teach about code review?

hard

A. {3: 6, 4: 8, 5: 10} - Code review helps spot logic and mutation issues

B. {1: 2, 2: 4, 3: 6, 4: 8, 5: 10} - Code review ensures all data processed

C. Error - Code review prevents runtime exceptions

D. {3: 10, 4: 8, 5: 10} - Code review helps catch unintended data changes

Solution

1. Step 1: Understand dictionary comprehension with condition

   Creates dict with keys 3,4,5 and values doubled: {3:6,4:8,5:10}.

2. Step 2: Note mutation of result[3]

   Code changes key 3's value from 6 to 10 explicitly.

3. Step 3: Final output and lesson

   Prints {3:10,4:8,5:10}. Code review helps catch such unintended mutations.

4. Final Answer:

   {3: 10, 4: 8, 5: 10} - Code review helps catch unintended data changes -> Option D

5. Quick Check:

   Mutation changes dict; review catches it [OK]

Hint: Check data changes carefully during review [OK]

Common Mistakes:

• Ignoring dictionary mutation after comprehension
• Assuming all data keys included
• Expecting error instead of changed output