5 exercises — practise the English terms for test doubles, runner hooks, assertion matchers, the test pyramid, and CI/CD pipeline testing language.
0 / 10 completed
1 / 10
A developer is writing a unit test for an email notification service. They want to replace the real email-sending dependency with a fake that simply returns a success response without sending any actual email, and they do not need to verify how many times the method was called. Which test double should they use?
A stub returns canned responses; a mock verifies interactions; a spy records real calls; a fake is a lightweight working implementation.
The scenario explicitly states "no need to verify how many times it was called" — this rules out a mock (which sets expectations and fails tests when they're not met) and a spy (which records calls for later assertion). A fake would be a real in-memory implementation, which is heavier than needed here. A stub is the exact fit: you pre-configure it to return a success response, use it in the test to isolate the email dependency, and never assert anything about its call history.
Key vocabulary:
• Stub — returns hard-coded/pre-configured responses; no interaction verification
• Mock — pre-programmed with expectations; test fails if expectations are not met
• Spy — wraps a real object and records calls; asserted after the fact
• Fake — a simplified but working implementation (e.g. in-memory DB, fake SMTP server)
• Test double — the umbrella term for any object replacing a real dependency in a test
2 / 10
In a Jest test suite, the beforeEach hook is used inside a describe block. What best describes its purpose?
beforeEach runs before every test — it's the standard way to reset state and prevent test pollution.
Option A describes beforeAll — which runs once before all tests in the block. Option B describes something like afterEach (runs after each test). Option C describes afterAll — which runs once when all tests in the block finish. beforeEach specifically runs its callback immediately before each individual it() or test() call, making it ideal for resetting mocks (e.g. jest.resetAllMocks()), recreating test fixtures, or reinitialising the system under test — so each test starts from a known, isolated state.
Key vocabulary:
• beforeEach — runs setup before every individual test in the enclosing describe block
• afterEach — runs teardown/cleanup after every individual test
• beforeAll — runs once before all tests in the block (expensive setup, e.g. DB connection)
• afterAll — runs once after all tests complete (e.g. close DB connection, delete temp files)
• Test pollution — when state from one test accidentally affects the result of another
3 / 10
A Jest test contains: expect(result).toContain('success'). Which assertion most accurately describes what this checks?
toContain checks for inclusion — not equality, not prefix, not object keys.
Option A describes toEqual or toBe — which require the entire value to match. Option B describes a toMatch with a start-anchor regex. Option D describes a property-access assertion (e.g. toHaveProperty). toContain is specifically an inclusion check: for strings it verifies the substring is present anywhere in the value; for arrays it verifies the element exists in the array. So expect('payment success confirmed').toContain('success') passes, and expect(['error','success']).toContain('success') also passes.
Key vocabulary:
• toContain — asserts that a string includes a substring or an array includes an element
• toEqual — asserts deep equality (entire structure and value must match)
• toBe — asserts strict reference equality (===)
• toMatch — asserts a string matches a regex or substring pattern
• toHaveProperty — asserts an object has a specified key (and optionally a specific value)
4 / 10
Your team's automated test suite has 2,000 unit tests, 150 integration tests, and 500 end-to-end tests. A senior engineer says this "inverts the test pyramid." What is the problem?
The test pyramid prescribes: many unit tests → fewer integration tests → very few E2E tests.
Option A is wrong: the pyramid deliberately recommends more unit tests than anything else for speed and isolation. Option B is an architectural opinion, not the core pyramid principle. Option D is incorrect: E2E tests are slow, brittle, and cannot isolate the cause of failures — they are a poor substitute for unit tests. The classic pyramid problem is having too many E2E tests relative to the layers below them. 500 E2E vs. 150 integration tests is an inverted ratio: E2E tests are slower, more expensive, and harder to debug, so having more of them than integration tests creates a fragile, slow suite.
Key vocabulary:
• Test pyramid — a model prescribing: many unit tests, fewer integration tests, fewest E2E tests
• E2E (end-to-end) test — tests the full system from UI to database; slow and brittle
• Integration test — tests interactions between two or more components or services
• Unit test — tests a single function or class in isolation; fastest and most deterministic
• Inverted pyramid (ice cream cone) — anti-pattern with too many slow E2E tests and too few unit tests
5 / 10
A CI/CD pipeline notification reads: "Build #412 failed — 3 flaky tests detected on main." Which interpretation is the most accurate?
Flaky tests fail non-deterministically — they do not indicate a code regression, but they do degrade pipeline reliability.
Option A describes a regression — a reproducible, deterministic failure caused by a code change. Option B describes a performance issue, not a flakiness report. Option C describes a configuration error, which would typically manifest as an error/skipped status, not "flaky." Flaky tests are the specific term for tests that produce inconsistent results without code changes — often due to race conditions, hardcoded timeouts, shared state, or external service dependencies. Best practice is to quarantine them (tag and skip in main), file a ticket, and investigate root causes before re-enabling.
Key vocabulary:
• Flaky test — a test that non-deterministically passes and fails without code changes
• Non-deterministic — producing different outputs from the same inputs on different runs
• Quarantine — isolating flaky tests from the main pipeline to prevent false build failures
• Race condition — a timing-dependent bug where test outcome depends on execution order
• Build red / build green — CI pipeline status: red = failing tests; green = all tests pass
6 / 10
Alice, a QA engineer, is reviewing a PR that includes a new API endpoint for user authentication. The code contains several tests using the `assert` library, but they lack specific assertions about response codes and data validation. Which of the following phrases would Bob, a senior developer, most likely suggest to improve the test coverage?
This scenario focuses on validating test coverage within a PR review. The correct answer emphasizes the need for HTTP status code assertions (like 200 or 400) and data schema validation – these are crucial aspects of robust API testing that often miss in simpler tests. Options A and C represent insufficient focus, while option D promotes overly simplistic testing which can mask critical issues.
7 / 10
Charlie, a junior developer, is writing a test for a function that calculates shipping costs. He uses the following code in his Jest test: `expect(calculateShippingCost(100)).toBeGreaterThanOrEqual(20);`. What does this assertion primarily verify?
This question tests understanding of `toBeGreaterThanOrEqual` in Jest assertions. The correct answer accurately reflects the function's intended behavior – that the shipping cost must be at least $20. Options B and C misinterpret the assertion's meaning regarding 'greater than' versus 'greater than or equal to.' Option D suggests a misunderstanding of the assertion itself.
8 / 10
David is writing a Slack message to report a failing automated test. The message reads: 'Build #789 failed – 5 tests failed due to intermittent network issues.' What does the term 'intermittent' most likely refer to in this context?
This explores understanding the meaning of 'intermittent' in the context of flaky tests. The correct answer highlights that intermittent failures mean the tests *occasionally* fail but can be reproduced given the right circumstances. Options A describes consistent failure, B misrepresents the term's meaning, and C is a contradiction.
9 / 10
Eve is participating in a stand-up meeting. Her manager asks, 'What's blocking you on the integration test for the new payment gateway?' Eve responds: 'The tests are failing intermittently because of a race condition when multiple users try to process payments simultaneously.' What does 'race condition' mean in this situation?
This question focuses on understanding concurrency issues. The correct answer accurately defines a race condition – where the outcome of an operation depends on the unpredictable order in which multiple threads or processes access shared resources. Option A is too broad, B misinterprets the term, and C and D represent unrelated problems.
10 / 10
Frank is reviewing a pull request that includes a new feature for validating user input. The PR description states: 'This change improves data quality by ensuring all fields meet predefined criteria.' Which of the following best represents the purpose of this type of testing?
This question tests understanding of different types of testing. The correct answer – validation testing – directly aligns with the PR description's focus on ensuring user input meets predefined criteria. Options A and B refer to other testing methodologies, while C is a broader definition of validation and D describes performance testing.
This exercise, "Test Automation Framework Vocabulary", tests your understanding of testing & qa lab vocabulary and phrasing through 10 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this Testing & QA Lab exercise for?
It's designed for IT professionals and learners who want to sound natural discussing testing & qa lab topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more Testing & QA Lab exercises?
Browse the full Testing & QA Lab exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.