Important note, please read
We may take pictures while you are doing this activity.
The pictures will show an overall class activity (that may or may not show your face clearly);
no individual picture will be taken unless you notify me your preference.
I would like to post pictures of our activity on the class website.
I am asking for your consent to (i) take pictures while you are doing this activity and
(ii) post pictures on the course website.
If you do not agree to give your consent, please
email me.
I will exclude any pictures that show your face.
For this activity, we will stop periodically and do group work one step at a time with discussion between steps.
Form groups of 4-5. To get started, use the two-breath rule, introduce yourself. Get to know everyone in your development and testing team. Work with your team and complete the following tasks.
You may make a copy of a worksheet and complete this activity, or simply type your answers in any text editor.
Follow the TDD process step-by-step and use the provided supplies to build a catapult.
There are two goals here. First, learning TDD is best accomplished by doing TDD. Second, applying TDD to develop software applications follows a similar process, with additional steps involving test code, test automation, and code refactoring.
Imagine your team is building a catapult for an Awesome Catapult Fair. You may use your creativity + STEM + imagination to design and develop a catapult any way you like, as long as your catapult is functioning. That is, it must be able to shoot an object for some distance.
(This activity would be more fun if you put your creativity + logic into designing and developing a catapult!!)
Let's try!!
The following are sample user stories. You may use the samples as a starting point and add more user stories to completely describe your catapult, specifically what it has and what it can do, or you may write your user stories from scratch.
User story #1: A catapult has a container to hold an object.
User story #2: A catapult has a lever to launch an object.
User story #3: A user presses a launching arm to shoot an object.
In this step, you will transform the user story into requirements. That is, you will decompose the user story into a list of "requirements as tests" — things to verify (not "requirements as tasks" — things to do)
Example requirement as test: (what should be done)
A container is attached to one end of a launching arm (stick).
Example requirement as task: (what we should do)
Add a container to one end of a launching arm (stick).
List the requirements — focus on requirements as tests, not requirements as tasks
Choose the first requirement to work on (you will work on all of your requirements; however, you will do one at a time).
Note that some requirements (as tests) that are specific and descriptive may be used as test harnesses directly. Some requirements (as tests) may need to be transformed into test descriptions.
Test description is a concrete, executable, and example-like version of the requirement.
Example test description:
A catapult can shoot an object over 3 feet.
Key idea:
Choose a test from the previous step. Use it as a test harness to build a catapult.
Key idea:Build "just enough" to pass the test
Key idea:Consider the part being developed. Can the part be improved? Does it need refactoring? Refactor it.
Consider the test harness. Can the test harness be improved? Does it need refactoring? Refactor it.
Key idea:Note: to help you review the TDD concept, you should use the TDD slides for reference.
Think about your experience with the activity and answer the following questions.
CC-BY-NC-SA 4.0 license.