בדיקות לקוד שכבר כתוב

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

קוד ומפתחים · בדיקות · tests · איכות · מקרי קצה

Write tests for this code.

[paste the code]

Test framework: [name it, e.g. node:test, vitest, jest, pytest]

Before writing any test code, list what is worth testing, in this order:
1. Edge cases: empty input, single item, maximum size, zero, negative, null and undefined.
2. Boundaries: exactly at the limit, one below, one above.
3. Invalid input that a real user would actually produce, not theoretical garbage.
4. Error paths: what should happen when a dependency fails or returns nothing.
5. The happy path, last and briefly.

Then write the tests.

Rules:
- Each test name states the expected behavior, not the function name.
- One assertion concept per test. Do not bundle unrelated checks.
- No mocking of the thing under test. Mock only external boundaries: network, filesystem, clock, randomness.
- Tests must be deterministic. No reliance on real time, real network, or execution order.
- If a case cannot be tested without changing the code, say so and explain what would need to change, instead of writing a test that passes for the wrong reason.

Finally, tell me which of these tests would have caught a real bug, and which exist only for coverage.

איך להשתמש בזה נכון