0
0
Software Engineeringknowledge~10 mins

Test-driven development (TDD) in Software Engineering - Interactive Code Practice

Choose your learning style9 modes available
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to describe the first step of TDD.

Software Engineering
In TDD, the first step is to write a [1] before writing any actual code.
Drag options to blanks, or click blank then click option'
Atest
Bfunction
Cdocumentation
Dcomment
Attempts:
3 left
💡 Hint
Common Mistakes
Writing the function before the test
Writing documentation first instead of a test
2fill in blank
medium

Complete the sentence to explain the TDD cycle.

Software Engineering
The TDD cycle is often described as Red, [1], Refactor.
Drag options to blanks, or click blank then click option'
ARun
BRewrite
CReview
DGreen
Attempts:
3 left
💡 Hint
Common Mistakes
Confusing 'Green' with 'Run' or 'Review'
Thinking the cycle is Red, Run, Refactor
3fill in blank
hard

Fix the error in the TDD description.

Software Engineering
In TDD, you write the code first, then write tests to check it. This is called [1].
Drag options to blanks, or click blank then click option'
ATest-driven development
BBehavior-driven development
CTest-last development
DCode-first development
Attempts:
3 left
💡 Hint
Common Mistakes
Confusing TDD with writing tests after code
Mixing up different development approaches
4fill in blank
hard

Fill both blanks to complete the TDD workflow.

Software Engineering
First, write a failing [1]. Then, write just enough [2] to pass it.
Drag options to blanks, or click blank then click option'
Atest
Bcode
Cdocumentation
Dscript
Attempts:
3 left
💡 Hint
Common Mistakes
Writing code before the test
Confusing documentation with tests
5fill in blank
hard

Fill all three blanks to describe the benefits of TDD.

Software Engineering
TDD helps improve [1], reduces [2], and encourages [3] design.
Drag options to blanks, or click blank then click option'
Acode quality
Bbugs
Cbetter
Dfaster
Attempts:
3 left
💡 Hint
Common Mistakes
Choosing 'faster' instead of 'better' for design
Mixing up benefits with unrelated terms