בדיקות פרונטאנד עם Jest, React Testing Library ו-MSW

אתה מריץ את npm test ו-15 בדיקות נכשלות עקב מוקים לא יציבים או תצורה שגויה. נשמע מוכר? אנחנו עוזרים להקים בדיקות יחידה אמינות: מגדירים את Jest, מחברים את הכלים הנכונים ומכסים מודולים קריטיים בבדיקות. כתוצאה מכך, הצוות שלך מפסיק לפחד מרפקטורינג, ו-CI מייצר סטטוס ירוק יציב. לצוות שלנו יש ניסיון של 7+ שנים באוטומציית בדיקות והוא ביצע 50+ פרויקטים של בדיקות יחידה לפרונטאנד. אנחנו בשוק בדיקות הפרונטאנד כבר 5+ שנים. אנחנו עובדים עם פרויקטים בכל רמת מורכבות: מאפליקציות דף יחיד ועד פורטלים ארגוניים גדולים. אנחנו לא רק כותבים בדיקות — אנחנו מתכננים ארכיטקטורה ניתנת לבדיקה.

לפי הסטטיסטיקות של הפרויקטים שלנו, הטמעת בדיקות יחידה מפחיתה את זמן בדיקות הרגרסיה ב-40% ומקטינה באגים בייצור ב-25%. זה חיסכון ישיר בתקציב QA ותמיכה — בממוצע 2–3 חודשי עבודת QA, שמסתכם בחיסכון של $2k–5k לשנה עבור צוות של 5 מפתחים. יתר על כן, בדיקות כתובות היטב משמשות כתיעוד ומפשטות את קליטת מפתחים חדשים.

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

אילו בעיות בדיקות יחידה פותרות?

• בדיקות לא יציבות עקב מוקים שגויים וסביבה מלוכלכת. פרויקט טיפוסי עם 20–30 רכיבים דורש ניהול מצב ומוקינג זהירים.
• חוסר כיסוי להוקים מותאמים אישית ורידוסרים — הלוגיקה נשארת לא מוגנת. ללא בדיקות, כל רפקטורינג הוא סיכון.
• תצורה מורכבת של Jest+React+TypeScript — בלבול עם טרנספורמציות, אליאסים וסגנונות. אנחנו מגדירים הכל מ-jest.config.ts ועד setupFilesAfterFramework, תוך שימוש בטכנולוגיות מודרניות: Jest 29, @swc/jest לטרנספורמציות מהירות, React Testing Library לרכיבים, ו-MSW למוקינג API.

ההתקנה אורכת 2–4 שעות, והתוצאה היא CI יציב וחיסכון תקציבי מוחשי.

איך מגדירים את Jest לפרויקט React עם TypeScript?

התצורה הסטנדרטית כוללת:

npm install -D jest @types/jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom 

// jest.config.ts
export default {
  testEnvironment: 'jsdom',
  setupFilesAfterFramework: ['<rootDir>/jest.setup.ts'],
  moduleNameMapper: {
    '^@/(.*)$': '<rootDir>/src/$1',
    '\.(css|scss)$': 'identity-obj-proxy',
  },
  transform: {
    '^.+\\.(ts|tsx)$': ['@swc/jest'],
  },
  coverageThreshold: {
    global: {
      branches: 70,
      functions: 80,
      lines: 80,
    },
  },
};

התצורה הזו תומכת באליאסים, מודולי CSS ו-TypeScript. npm install -D jest @types/jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom מבטיח רמת כיסוי מינימלית — אחרת ה-pipeline נכשל. לפרטים נוספים על ההתקנה, עיינו בתיעוד הרשמי של Jest.

עבור פרויקטים ב-Next.js או Vue, נדרשים שינויים קלים: הוספת // jest.config.ts export default { testEnvironment: 'jsdom', setupFilesAfterFramework: ['<rootDir>/jest.setup.ts'], moduleNameMapper: { '^@/(.*)$': '<rootDir>/src/$1', '\.(css|scss)$': 'identity-obj-proxy', }, transform: { '^.+\.(ts|tsx)$': ['@swc/jest'], }, coverageThreshold: { global: { branches: 70, functions: 80, lines: 80 }, }, }; והגדרת טרנספורמציות עבור הפריימוורק שלכם. אנחנו מתאימים את התצורה באופן אישי.

למה לבדוק הוקים מותאמים אישית ובקשות אסינכרוניות?

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

השוואה בין גישות למוקינג API

MSW עולה על מוקים ידניים פי 2–3 במהירות ביצוע הבדיקות ומדמה בצורה מדויקת יותר את התנהגות השרת.

מה כלול בעבודה

• Jest מוגדר עם תצורה מותאמת לטכנולוגיות שלכם.
• 30–50 בדיקות יחידה לכלים, הוקים, רכיבים ושירותים.
• אינטגרציית CI/CD (GitHub Actions, GitLab CI, Jenkins).
• תיעוד על הרצה, הוספת בדיקות חדשות ועבודה עם מוקים.
• הבטחת יציבות: בדיקות עוברות, הכיסוי לא יורד מתחת לסף המוסכם (בדרך כלל 80%).

דוגמאות בדיקות

בדיקת כלים

// src/utils/currency.ts
export const formatCurrency = (amount: number, locale = 'ru-RU', currency = 'USD') =>
  new Intl.NumberFormat(locale, { style: 'currency', currency }).format(amount);

// src/utils/currency.test.ts
describe('formatCurrency', () => {
  it('formats USD correctly', () => {
    expect(formatCurrency(1500)).toMatch('1 500');
  });

  it('handles zero', () => {
    expect(formatCurrency(0)).toMatch('0');
  });

  it('formats USD', () => {
    expect(formatCurrency(99.99, 'en-US', 'USD')).toBe('$99.99');
  });
});

בדיקת רכיבי React

// components/Button.test.tsx
import { render, screen, fireEvent } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { Button } from './Button';

describe('Button', () => {
  it('renders label', () => {
    render(<Button>Сохранить</Button>);
    expect(screen.getByRole('button', { name: 'Сохранить' })).toBeInTheDocument();
  });

  it('calls onClick', async () => {
    const onClick = jest.fn();
    render(<Button onClick={onClick}>Click me</Button>);
    await userEvent.click(screen.getByRole('button'));
    expect(onClick).toHaveBeenCalledTimes(1);
  });

  it('disabled button does not fire onClick', async () => {
    const onClick = jest.fn();
    render(<Button onClick={onClick} disabled>Disabled</Button>);
    await userEvent.click(screen.getByRole('button'));
    expect(onClick).not.toHaveBeenCalled();
  });

  it('shows loading spinner when loading', () => {
    render(<Button loading>Save</Button>);
    expect(screen.getByRole('button')).toHaveAttribute('aria-busy', 'true');
    expect(screen.getByTestId('spinner')).toBeInTheDocument();
  });
});

בדיקת בקשות API

// services/api.test.ts
import { rest } from 'msw';
import { setupServer } from 'msw/node';
import { fetchUser } from './api';

const server = setupServer(
  rest.get('/api/users/:id', (req, res, ctx) => {
    return res(ctx.json({ id: 1, name: 'Иван' }));
  })
);

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

test('fetchUser returns user data', async () => {
  const user = await fetchUser(1);
  expect(user.name).toBe('Иван');
});

test('fetchUser handles 404', async () => {
  server.use(
    rest.get('/api/users/:id', (req, res, ctx) => res(ctx.status(404)))
  );
  await expect(fetchUser(999)).rejects.toThrow('Not found');
});

הגישה שלנו: מקרה בוחן אמיתי

בפרויקט מסחר אלקטרוני עדכני, קיבלנו קוד React עם 150+ רכיבים ואפס בדיקות. ה-CI pipeline ארך 45 דקות, וכל דיפלוי היה מסוכן. הגדרנו את Jest עם @swc/jest ו-MSW, ואז כתבנו 80 בדיקות שכיסו את הלוגיקה העסקית המרכזית (עגלה, תשלום, רשימת מוצרים). זמן ביצוע הבדיקות ירד מ-12 דקות ל-3 דקות. סף הכיסוי של 80% הושג, ושיעור באגי הרגרסיה ירד ב-60%. הלקוח חסך בערך חודשיים של עבודת QA לכל מחזור שחרור.

תהליך העבודה

1. ניתוח פרויקט: מבנה, מודולים עיקריים, נתיבים קריטיים. אורך 2–4 שעות.
2. הגדרת Jest וסביבת הבדיקות. חיבור ספריות, הגדרת אליאסים.
3. כתיבת בדיקות (2–4 ימים) עם עדיפות ללוגיקה עסקית. כתיבת בדיקות לכלים, הוקים, רכיבים ו-API.
4. אינטגרציית CI — הוספת שלב coverageThreshold.
5. מסירת תיעוד וייעוץ לצוות.

הערכות זמנים

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

פנו אלינו לייעוץ — נספר לכם איך לשפר כיסוי ולהאיץ את ה-CI. הזמינו בדיקות יחידה במפתח פתוח וקבלו ייצור יציב.