Introduction to Test Driven Development

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
(Intro to TDD activity initial commit)
 
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
{| border="1"
+
 
|-
+
{{Learning Activity Overview
|'''Title''' || 
+
|title=
 
Introduction to Test-Driven Development (TDD)
 
Introduction to Test-Driven Development (TDD)
|-   
+
|overview=
|'''Overview''' || 
+
Participants write a unit test (in [[:Category:Google Test|Google Test]]) and corresponding C++ code to pass the test to verify the test passes
Participants write a unit test (in GoogleTest) and corresponding C++ code to pass the test to verify the test passes
+
|prerequisites=
|'''Prerequisite Knowledge''' ||
+
Google Test needed to have been installed (as instructed in [[Unit Test With GoogleTest Activity]]) and intermediate C++ expertise.
GoogleTest needed to have been installed (as instructed in [[Unit Test With GoogleTest Activity]]) and intermediate C++ expertise.
+
|objectives=
|-
+
Follow "Red light, green light" Test-Driven Development process and reflect over the approach.
|'''Learning Objectives''' ||
+
|process skills=
Participant should be able to learn how to follow "Red light, green light" Test-Driven Development process and reflect over the approach.
+
}}
|}
+
  
=== Directions: ===
+
=== Directions ===
  
==== Students: ====
+
==== Students ====
  
*This exercise continues from [[Unit Test With GoogleTest Activity]]
+
* This exercise continues from [[Unit Test With GoogleTest Activity]]
*Open the local directory where you cloned [https://github.com/ChicoState/cpp-gtest cpp-gtest].
+
* Open the local directory where you cloned [https://github.com/ChicoState/cpp-gtest cpp-gtest].
*Edit <code>RandoTest.cpp</code> and review the syntax of the tests we used for the <code>shouldWorry</code> function, which should look like:
+
* Edit <code>RandoTest.cpp</code> and review the syntax of the tests we used for the <code>shouldWorry</code> function, which should look like:
 
<code>
 
<code>
 
TEST(/*ClassName*/, /*DescriptiveNameOfTest*/)<br/>{<br/>&nbsp;/**<br/>&nbsp;&nbsp;* Declare an object of the class' type<br/>&nbsp;&nbsp;* then call the function and assert your expected outcome<br/>&nbsp;**/<br/>}<br/>
 
TEST(/*ClassName*/, /*DescriptiveNameOfTest*/)<br/>{<br/>&nbsp;/**<br/>&nbsp;&nbsp;* Declare an object of the class' type<br/>&nbsp;&nbsp;* then call the function and assert your expected outcome<br/>&nbsp;**/<br/>}<br/>
 
</code>
 
</code>
  
*Write one (and only one) test for the function isDivisibleBy:
+
* Write one (and only one) test for the function <code>isDivisibleBy</code>:
 
<code>
 
<code>
 
&nbsp;/**<br/>
 
&nbsp;/**<br/>
Line 31: Line 30:
 
&nbsp;**/<br/>
 
&nbsp;**/<br/>
 
</code>
 
</code>
*Next, make the project. After it builds, run <code>./RandoTest.</code> Your test should fail (and highlight in red).
+
* Next, make the project. After it builds, run <code>./RandoTest.</code> Your test should fail (and highlight in red).
*Since you now have a failing test, you should write code specifically to resolve that failed test. Edit <code>rando.cpp</code> to update the solution. When you think you have resolved the failed test, repeat building the project and running the tests. If your test still fails, return and continue to fix the function until it passes.
+
* Since you now have a failing test, you should write code specifically to resolve that failed test. Edit <code>rando.cpp</code> to update the solution. When you think you have resolved the failed test, repeat building the project and running the tests. If your test still fails, return and continue to fix the function until it passes.
*Once your first test passes, then you can repeat this process: write a test, run the test (with failure), write the solution, run the test (until passing).
+
* Once your first test passes, then you can repeat this process: write a test, run the test (with failure), write the solution, run the test (until passing).
*Repeat this process until you have decided that your tests would fail any wrong implementation and would pass any right implementation. Then, read over your implemented code and refactor it to make sure it uses good style, is consistent with its documentation, and fits within its class.
+
* Repeat this process until you have decided that your tests would fail any wrong implementation and would pass any right implementation. Then, read over your implemented code and refactor it to make sure it uses good style, is consistent with its documentation, and fits within its class.
*This method is specifically called "Red Light, Green Light" Test-Driven Development, where the green light represents a passing test that indicates you can go on to the next test-develop cycle. Test-Driven Development was popularized as a part of [https://en.wikipedia.org/wiki/Extreme_programming eXtreme Programming by Kent Beck] who summarized it as "Test-a-little, Code-a-little."
+
* This method is specifically called "Red Light, Green Light" Test-Driven Development, where the green light represents a passing test that indicates you can go on to the next test-develop cycle. Test-Driven Development was popularized as a part of [https://en.wikipedia.org/wiki/Extreme_programming eXtreme Programming by Kent Beck] who summarized it as "Test-a-little, Code-a-little."
*Now that you have practiced Test-Driven Development (TDD), write one paragraph to summarize your thoughts. How did testing first impact how you thought about the problem? What do you think is the biggest benefit of TDD? What do you find most challenging? Submit your paragraph for this assignment.
+
* Now that you have practiced Test-Driven Development (TDD), write one paragraph to summarize your thoughts. How did testing first impact how you thought about the problem? What do you think is the biggest benefit of TDD? What do you find most challenging? Submit your paragraph for this assignment.
  
=== Deliverables: ===
+
=== Deliverables ===
  
 
A paragraph reflecting on first experiences with Test-Driven Development
 
A paragraph reflecting on first experiences with Test-Driven Development
  
=== Assessment: ===
+
=== Assessment ===
  
Students should demonstrate meta-cognition of reflecting over their first experience with Test-Driven Development and how it impacted their approach to programming
+
Students should demonstrate meta-cognition of reflecting over their first experience  
 +
with Test-Driven Development and how it impacted their approach to programming
  
=== Comments: ===
+
=== Comments ===
  
=== Additional Information: ===
+
=== Additional Information ===
{| border="1"
+
 
|-
+
{{Learning Activity Info
|'''Knowledge Area/Knowledge Unit''' || 
+
|acm unit=
Softward Engineering
+
Software Engineering / SE Software Verification Validation
|-
+
|acm topic=
|'''Topic''' || 
+
 
Test-Driven Development
 
Test-Driven Development
|-
+
|difficulty=
|'''Level of Difficulty''' || 
+
 
Programming a new unit test takes intermediate expertise of C++ and imperative programming
 
Programming a new unit test takes intermediate expertise of C++ and imperative programming
|-
+
|time=
|'''Estimated Time to Completion''' ||
+
 
Writing a new unit test and its corresponding solution should take between 20-40 minutes. Writing a reflection on the process should take an additional 10 minutes for a total of up to 50 minutes.
 
Writing a new unit test and its corresponding solution should take between 20-40 minutes. Writing a reflection on the process should take an additional 10 minutes for a total of up to 50 minutes.
|-
+
|environment=
|'''Materials/Environment''' ||
+
 
Need to have completed [Unit Test With GoogleTest Activity] installation process
 
Need to have completed [Unit Test With GoogleTest Activity] installation process
|-
+
|author=
|'''Author''' || 
+
 
Kevin Buffardi
 
Kevin Buffardi
|-
+
|source=
|'''Source''' ||
+
 
Kevin Buffardi
 
Kevin Buffardi
|-
+
|license=
|'''License''' ||
+
{{License CC BY SA}}
Licensed CC BY-SA 4.0
+
}}
|}
+
 
+
 
+
--------------------
+
This work is licensed under a
+
[http://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International License]
+
 
+
[[File:CC_license.png]]
+
  
[[Category: Learning_Activity]]
+
[[Category:Learning Activity]]
[[Category: Quality_and_Testing]]
+
[[Category:Quality and Testing]]
 +
[[Category:Google Test]]
 +
[[Category:Good Draft]]

Latest revision as of 13:32, 8 September 2018


Title

Introduction to Test-Driven Development (TDD)

Overview

Participants write a unit test (in Google Test) and corresponding C++ code to pass the test to verify the test passes

Prerequisites

Google Test needed to have been installed (as instructed in Unit Test With GoogleTest Activity) and intermediate C++ expertise.

Learning
Objectives
After successfully completing this activity, the learner should be able to:

Follow "Red light, green light" Test-Driven Development process and reflect over the approach.

Process Skills
Practiced


Directions

Students

  • This exercise continues from Unit Test With GoogleTest Activity
  • Open the local directory where you cloned cpp-gtest.
  • Edit RandoTest.cpp and review the syntax of the tests we used for the shouldWorry function, which should look like:

TEST(/*ClassName*/, /*DescriptiveNameOfTest*/)
{
 /**
  * Declare an object of the class' type
  * then call the function and assert your expected outcome
 **/
}

  • Write one (and only one) test for the function isDivisibleBy:

 /**
  * Determines if first or second are evenly divisible by the other.
 **/

  • Next, make the project. After it builds, run ./RandoTest. Your test should fail (and highlight in red).
  • Since you now have a failing test, you should write code specifically to resolve that failed test. Edit rando.cpp to update the solution. When you think you have resolved the failed test, repeat building the project and running the tests. If your test still fails, return and continue to fix the function until it passes.
  • Once your first test passes, then you can repeat this process: write a test, run the test (with failure), write the solution, run the test (until passing).
  • Repeat this process until you have decided that your tests would fail any wrong implementation and would pass any right implementation. Then, read over your implemented code and refactor it to make sure it uses good style, is consistent with its documentation, and fits within its class.
  • This method is specifically called "Red Light, Green Light" Test-Driven Development, where the green light represents a passing test that indicates you can go on to the next test-develop cycle. Test-Driven Development was popularized as a part of eXtreme Programming by Kent Beck who summarized it as "Test-a-little, Code-a-little."
  • Now that you have practiced Test-Driven Development (TDD), write one paragraph to summarize your thoughts. How did testing first impact how you thought about the problem? What do you think is the biggest benefit of TDD? What do you find most challenging? Submit your paragraph for this assignment.

Deliverables

A paragraph reflecting on first experiences with Test-Driven Development

Assessment

Students should demonstrate meta-cognition of reflecting over their first experience with Test-Driven Development and how it impacted their approach to programming

Comments

Additional Information

ACM BoK
Area & Unit(s)

Software Engineering / SE Software Verification Validation

ACM BoK
Topic(s)

Test-Driven Development

Difficulty

Programming a new unit test takes intermediate expertise of C++ and imperative programming

Estimated Time
to Complete

Writing a new unit test and its corresponding solution should take between 20-40 minutes. Writing a reflection on the process should take an additional 10 minutes for a total of up to 50 minutes.

Environment /
Materials

Need to have completed [Unit Test With GoogleTest Activity] installation process

Author(s)

Kevin Buffardi

Source

Kevin Buffardi

License

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License

CC license.png

Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox