ריפקטורינג טוב יותר מ Mock-ים

03/01/2024

הדוגמה היום היא בפייתון אבל הקונספט נכון בכל שפה. הקוד הבא הוא מימוש למשחק ניחוש מספרים. נכון הוא לא מתוחכם במיוחד אבל יעבוד בשביל הדוגמה. המחשב מגריל מספר סודי, אתה מנסה לנחש אותו והמחשב עונה ב"גדול מדי" או "קטן מדי" עד שמגיעים למספר הנכון. זה קוד שעובד:

def main():
    secret_number = random.randint(1, 100)
    while True:
        next_guess = int(input("Next guess: "))
        if next_guess == secret_number:
            print("Bravo! You guessed it")
            break
        elif next_guess < secret_number:
            print("Sorry, too small")
        else:
            print("Sorry, too large")

כל מה שצריך בשביל לבדוק את הקוד הוא לכתוב כמה Mock-ים, למשל לדרוס את input ואת random.randint ואז להסתכל מה הודפס. למשל הבדיקה הבאה מוודאת שכשמשתמש מנחש את המספר התוכנית תדפיס את ההודעה הנכונה ותצא מהלולאה:

def test_stop_when_guess_is_correct(capsys):
    with patch('builtins.input', new=lambda _: "10\n"):
        with patch('random.randint') as randint:
            randint.return_value = 10
            main()
            assert capsys.readouterr()[0] == "Bravo! You guessed it\n"

זה נהיה קצת יותר מסובך כשרוצים לוודא את התשובה של המשחק לניחוש גבוה מדי:

def test_says_too_small_when_guessing_small_number(capsys):
    with patch('builtins.input') as fake_input:
        with patch('random.randint') as randint:
            fake_input.side_effect = ["10\n"]
            randint.return_value = 30
            try:
                main()
            except StopIteration:
                pass
            assert capsys.readouterr()[0] == "Sorry, too small\n"

בתוכנית אמיתית עם הרבה יותר תלויות מערכת ה Mock-ים תצא מהר משליטה. הבדיקות יהיו מסובכות ויקשו על ריפקטורינג של הקוד, עד שבדיקות יתחילו להיכשל בצורה ספונטנית.

עכשיו ננסה תרגיל אחר והוא לארגן מחדש את הקוד כדי שלא נצטרך Mock-ים. בדיקות טובות עשויות להיראות כך:

def test_equal():
    assert game.check_user_input(20, "20\n") == game.TEXT['=']


def test_too_large():
    assert game.check_user_input(20, "50\n") == game.TEXT['>']


def test_too_small():
    assert game.check_user_input(20, "10\n") == game.TEXT['<']


def test_stop_when_equal(capsys):
    game.game(50, ["20\n", "40\n", "50\n", "80\n"])
    assert capsys.readouterr()[0] == f"""{game.TEXT['<']}
{game.TEXT['<']}
{game.TEXT['=']}
"""

נשים לב שכל בדיקה הפעם בודקת בדיוק את מה שהיא צריכה בלי למלא את הפונקציה ב Boilerplate של דריסות. והקוד עצמו? הנה הגירסה החדשה שעושה בדיוק את אותו דבר ומתאימה לקוד הבדיקות החדש:

from typing import Callable
import random
import itertools

TEXT = {
    "=": "Bravo! You guessed it",
    "<": "Sorry, too small",
    ">": "Sorry, too large"
}

MIN = 1
MAX = 100


def check_user_input(secret_number: int, user_value: str) -> str:
    if int(user_value) == secret_number:
        return TEXT['=']
    elif int(user_value) < secret_number:
        return TEXT['<']
    else:
        return TEXT['>']


def input_stream():
    while True:
        yield input("Next Guess: ")

def secret_number_generator():
    return random.randint(MIN, MAX)


def game(secret_number, inputs):
    responses = (check_user_input(secret_number, i) for i in inputs)
    for response in responses:
        print(response)
        if response == TEXT['=']:
            break


if __name__ == "__main__":
    game(secret_number_generator(), input_stream())

ונכון זה קוד של 41 שורות במקום 18. ואני מכיר גם את הטיעון שקל יותר לתחזק קוד קצר מאשר קוד ארוך, והוא נכון במידה מסוימת. הבעיה שאחרי שהקוד עובר אורך מסוים הוא כבר לא נחשב "קצר". קוד של 20,000 שורות עם בדיקות וחלוקה נכונה לפונקציות הוא יותר קל לתחזוקה מאשר קוד של 10,000 שורות מבולגנות.