frontend-interview-questions

1. چگونه به تست کامپوننت‌های React نزدیک می‌شوید؟ از چه ابزارها یا کتابخانه‌هایی استفاده می‌کنید (مثل Jest، React Testing Library)؟

من بر تست رفتار به جای پیاده‌سازی تمرکز می‌کنم و از ابزارهای زیر استفاده می‌کنم:

• Jest برای تست‌های واحد و ادغام (اجرای سریع و قابل اعتماد).
• React Testing Library (RTL) برای تست تعامل مبتنی بر DOM که رفتار واقعی کاربر را شبیه‌سازی می‌کند.
• MSW (Mock Service Worker) برای مدل‌سازی پاسخ‌های API.
• Cypress یا Playwright برای تست‌های سرتاسری (E2E) که تعاملات واقعی مرورگر را شبیه‌سازی می‌کنند.

فلسفه من: کامپوننت‌ها را همان‌طور تست کنید که کاربران با آن‌ها تعامل می‌کنند — کلیک کردن، تایپ کردن و مشاهده خروجی‌ها — نه وضعیت داخلی.

2. یک مورد تست ساده برای یک کامپوننت React که یک دکمه رندر می‌کند و یک شمارشگر را با کلیک به‌روزرسانی می‌کند بنویسید.

// Counter.test.tsx
import { render, screen, fireEvent } from "@testing-library/react";
import Counter from "./Counter";

test("increments count on click", () => {
  render(<Counter />);
  fireEvent.click(screen.getByText(/increment/i));
  expect(screen.getByText(/count: 1/i)).toBeInTheDocument();
});

3. تفاوت بین تست واحد و تست ادغام در زمینه برنامه‌های React چیست؟

• تست واحد: یک کامپوننت را به‌صورت ایزوله تست می‌کند (مثل منطق، رندر، رویدادهای کاربر). مثال: تست یک هندلر کلیک کامپوننت Button.
• تست ادغام: نحوه کار چندین کامپوننت با هم را تست می‌کند. مثال: تست یک فرم که داده‌ها را از طریق API ارسال کرده و پیام موفقیت را رندر می‌کند.

تست‌های واحد سریع‌تر و متمرکزتر هستند؛ تست‌های ادغام اطمینان بیشتری برای جریان‌های واقعی فراهم می‌کنند.

4. چگونه یک فراخوانی API را در تست یک کامپوننت React مدل می‌کنید؟

من از MSW (Mock Service Worker) برای مدل‌سازی واقعی API در سطح شبکه استفاده می‌کنم.

مثال:

import { rest } from "msw";
import { setupServer } from "msw/node";

const server = setupServer(
  rest.get("/api/user", (req, res, ctx) => res(ctx.json({ name: "Alice" })))
);

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

این کار تست‌ها را به رفتار اپلیکیشن در تولید نزدیک نگه می‌دارد.

5. چگونه تست‌های واحد را برای یک کامپوننت React که به یک API خارجی وابسته است ساختاردهی می‌کنید؟

من منطق API را از کامپوننت رابط کاربری جدا کرده و هر دو را تست می‌کنم:

1. تست واحد کلاینت API به‌صورت جداگانه (مثل getUser()).
2. در تست کامپوننت:
   • لایه API را مدل می‌کنم (مثل استفاده از MSW یا مدل Jest).
   • رفتار رابط کاربری را تست می‌کنم (مثل اسپینر بارگذاری، پیام خطا، رندر داده).

این جداسازی قابلیت اطمینان و وضوح تست را بهبود می‌بخشد.

6. یک تست ادغام با استفاده از Cypress یا Playwright برای جریان ارسال فرم React بنویسید.

// cypress/e2e/form_spec.cy.js
describe("Contact Form", () => {
  it("submits the form successfully", () => {
    cy.visit("/contact");
    cy.get('input[name="email"]').type("test@example.com");
    cy.get('textarea[name="message"]').type("Hello!");
    cy.intercept("POST", "/api/contact", { statusCode: 200 }).as("submitForm");
    cy.get('button[type="submit"]').click();
    cy.wait("@submitForm");
    cy.contains("Thank you for contacting us").should("be.visible");
  });
});

7. رویکرد شما برای تست سرتاسری در یک برنامه React با چندین نقش کاربری چیست؟

من رفتار کاربر را بر اساس نقش‌ها (مثل مدیر در مقابل کاربر) شبیه‌سازی می‌کنم:

• استفاده از Cypress یا Playwright برای ورود به‌عنوان نقش‌های مختلف از طریق رابط کاربری یا تنظیم برنامه‌ریزی‌شده جلسه.
• تست جریان‌های مبتنی بر نقش:
  • مدیر: دسترسی به داشبورد، مدیریت کاربران
  • کاربر: دسترسی محدود، مسیرهای محدود شده
• پاسخ‌های احراز هویت را مدل کرده یا از حساب‌های تست seed شده در محیط‌های تست استفاده می‌کنم.
• موارد تست مبتنی بر نقش را سازمان‌دهی می‌کنم (مثل پوشه‌های admin/، user/).

8. چگونه اطمینان حاصل می‌کنید که پوشش تست معنادار باقی می‌ماند و صرفاً یک معیار برای دستیابی نیست؟

من بر ارزش تست تمرکز می‌کنم، نه فقط اعداد:

• هدف‌گذاری برای چگالی ادعای بالا — نه فقط خطوط “پوشش داده‌شده”، بلکه نتایج معتبر.
• اولویت‌بندی مسیرهای بحرانی: ارسال فرم، به‌روزرسانی‌های وضعیت، رندر شرطی.
• استفاده از ابزارهای پوشش کد (مثل -coverage در Jest) برای شناسایی شاخه‌های تست‌نشده — سپس تصمیم‌گیری در مورد ارزش تست آن‌ها.
• اجتناب از تست بیش از حد جزئیات پیاده‌سازی داخلی (مثل فراخوانی‌های setState).

بررسی‌های منظم تست و QA دستی به تقویت کیفیت فراتر از معیارها کمک می‌کنند.

This site is open source. Improve this page.