Sample questions
TestingDifficulty 1
Frontend tests are commonly split into unit, integration, and end-to-end. What does this split describe?
- aWhich team writes them — developers write the unit tests, while the QA and design teams own the end-to-end ones
- bWhich programming language each kind of test is required to be written in
- cWhether a test runs inside a real browser or only from the terminal
- dHow much of the system a test exercises: one unit, a few parts together, or the whole app via its UI✓
Explanation:The three levels describe scope: a unit test checks one small piece (like a single component), an integration test checks a few pieces working together, and an e2e test drives the whole app through its UI. It is not about who writes them (a) — developers commonly write all three levels.
TestingDifficulty 1
What is a component test primarily meant to check?
- aThat the component's source file compiles and passes the project's linter without any warnings at all
- bThat the full multi-page checkout flow works from start to finish
- cThat a single UI component, on its own, renders correctly and reacts to input as expected✓
- dThat the CSS bundle finishes loading before the JavaScript bundle
Explanation:A component test mounts one component in isolation and verifies its rendered output and its response to input (props, clicks, typing). Checking a full multi-page flow (b) is the job of an end-to-end test, not a component test.
TestingDifficulty 1
A UI test is structured as arrange–act–assert (AAA). What belongs in the act phase?
- aTrigger the user interaction under test, such as a click or typing✓
- bRender the component and set up its initial props, state, and any fakes
- cCheck that the expected text or element is now visible on screen
- dRemove the component from the DOM and reset any shared state
Explanation:Act performs the single behavior under test — the click or keystroke. Rendering and setting up state is the arrange phase (b), and checking the visible result is the assert phase (c).
TestingDifficulty 1
What is the difference between a happy-path test and an edge-case test?
- aHappy-path tests are run locally by developers during coding; edge-case tests are run only by the QA team before a release
- bHappy path uses valid input; an edge case probes unusual or boundary input like empty, zero, or very long values✓
- cHappy-path tests cover the UI layer; edge-case tests are limited to backend logic and databases
- dHappy-path tests need no assertions; edge-case tests are the only ones that assert an outcome
Explanation:The happy path exercises normal, valid input; edge cases probe boundaries and unusual input where bugs hide — empty strings, zero, negative or very long values. It is not about who runs them (a); both are ordinary developer tests.
TestingDifficulty 1
Why do teams usually write many component/unit tests but only a handful of end-to-end tests?
- aBecause end-to-end tests cannot run inside a continuous integration pipeline
- bBecause unit tests are the only kind that can find real bugs in UI code
- cBecause once component-level coverage is high enough, the integration between those components no longer needs any testing
- dBecause end-to-end tests are slower and more brittle, so a large number of them is costly to run and maintain✓
Explanation:It is about cost and stability: unit/component tests are fast and pinpoint failures, while e2e tests are slow and brittle, so keeping many of them is expensive. A few e2e tests remain essential — it is not that they cannot run in CI (a).
TestingDifficulty 1
Which best describes a frontend end-to-end (e2e) test?
- aIt renders one single component in isolation, with every one of its dependencies replaced by fakes and hand-written stubs
- bIt statically analyzes the source for type errors without running the code
- cIt drives the real, running app through the browser the way a user would, across real pages and requests✓
- dIt counts how many lines of the code base were executed at least once
Explanation:An e2e test behaves like a real user: it opens the assembled app in a browser and clicks through real pages and network calls. Rendering one component with faked dependencies (a) describes a component/unit test instead.