Practice test naming vocabulary: should_DoX_whenY pattern, Given_When_Then naming, tests as specifications, descriptive test names, and using failing test names to communicate failures.
0 / 10 completed
1 / 10
What does the 'should_DoX_whenY' test naming pattern communicate?
The 'should_DoX_whenY' pattern (e.g., should_returnNull_whenUserNotFound) expresses the test as a specification: under condition Y, the system should do X. This format makes the test's intent legible in the test runner output without having to open the test file — you can read test results like a specification document.
2 / 10
How does 'Given_When_Then' test naming differ from its use in Gherkin?
Given_When_Then can be used as a test method naming convention even without BDD tools like Cucumber. The full test name documents: the initial state (given_userIsAdmin), the action (when_deletePost), and the expected result (then_postIsDeleted). This is more verbose than should_DoX_whenY but provides maximum clarity in the test report output.
3 / 10
'The test name documents the behaviour.' What problem does poor test naming cause?
Poorly named tests like 'test1', 'testLogin', or 'shouldWork' provide no information when they fail. A well-named test like 'should_rejectLogin_whenPasswordExceedsMaxLength' tells you immediately what broke and in what context — you can often diagnose the issue from the test name alone without reading the test body.
4 / 10
'Test descriptions as specifications.' What approach does this phrase describe?
Treating tests as specifications means writing test names and docstrings that fully describe system behaviour, so the test suite reads like a requirements document. This is the core philosophy behind BDD and tools like RSpec (Ruby) which produce readable output: 'UserAuthentication: given valid credentials: should return a session token'. The test suite becomes self-documenting.
5 / 10
'The failing test name tells you exactly what broke.' Why is this quality of test names important in CI/CD?
In a fast CI/CD workflow, a developer gets a build failure notification. If the failing test is named 'should_calculateVAT_correctlyForEUCustomers', the developer immediately knows which feature broke and in what scenario. If it's named 'test47', they must open the CI logs, find the test, open the test file, and read it — wasting time. Descriptive names compress the triage cycle.
6 / 10
Reviewer Alex comments on a PR: 'This test doesn't really cover the edge case where the input string is empty. It just checks for a standard alphanumeric value.' What does Alex likely mean regarding the test naming pattern? assert(input == 'abc')
Alex highlights a key principle of test naming: tests must cover *all* relevant scenarios, not just the typical ones. The phrase 'doesn't really cover' suggests the test is incomplete and lacks sufficient detail to properly validate the code's behaviour. This aligns with the pattern of explicitly stating all conditions that need validation.
7 / 10
Sarah is drafting a PR description for a new feature: 'The API endpoint now handles negative integer IDs gracefully.' What test name would best complement this description? test_api_negative_id_handling
The PR description outlines a specific behaviour – handling negative IDs. 'test_api_post_user_data' is too generic and doesn't link to the core functionality being tested. 'test_api_validate_id_format…' is also vague. 'test_api_handle_negative_id' directly relates to the description, clearly specifying what the test verifies.
8 / 10
David in a standup update says: 'I wrote a test that checks if the user's email is valid. It uses a regular expression to ensure it matches the correct format.' Which of the following best describes the core principle David is employing? assert(email_regex.match(user_email))
David's statement emphasizes that the test name must explicitly state *how* the email is validated. The regular expression is a key component of the validation process and should be reflected in the test name to provide clarity and traceability. This is crucial for understanding the test's purpose and how it contributes to overall system robustness.
9 / 10
Maria in a Slack channel discusses test naming with her team: 'We need to ensure our tests accurately reflect the *expected* outcome of the code.' What does Maria primarily mean when referring to 'expected outcomes'? test_user_login_success
Maria's statement highlights that test names should focus on the desired result – the 'expected outcome.' This is a fundamental aspect of good test naming: tests should validate that the code behaves as intended, not just how it was implemented. This contrasts with simply describing the steps taken during execution.
10 / 10
A failing test name is: 'Test_UserLogin_Success'. The code under test has a bug that prevents users from logging in when they enter an incorrect password. What does this failing test name *fail* to communicate effectively? assert(user_logged_in)
The core principle of good test naming is that a failing test name should immediately reveal *what* went wrong. 'Test_UserLogin_Success' falsely suggests the test passed when it actually failed due to an incorrect password. A better name would have explicitly mentioned the failure condition (e.g., 'Test_UserLogin_IncorrectPassword').
What will I learn from the "Test Naming Vocabulary" exercise?
Practice test naming vocabulary: should_DoX_whenY pattern, Given_When_Then naming, tests as specifications, descriptive test names, and using failing test names to communicate failures.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this TDD/BDD Language exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss tdd/bdd language topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more TDD/BDD Language exercises?
See the full TDD/BDD Language exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.