Answers.Body: <p>The first problem my students always have with this is that they don't even understand <em>how</em> to test their code.  They've run the program, and it works.  So... it must work.</p>
  <p>I have two approaches to this, and while they definitely help, I will also be keeping an eye out on the other answers for more pointers.</p>
  <ul>
  <li><p>The first is simply to create test-cases together.  I have not made as formal a lesson about this as I would like to, but I opportunistically will create tests with the class when we code together on the projector.</p>
  <p>Thinking about this now, I would want to create a few methods with some non-obvious flaws (such as breaking on empty lists, odd numbers of items in an array, null entries within an array, negative numbers, etc), and provide .jar files with no source code.  Ask students to find the errors, and then reflect together on what kinds of tests were helpful.</p>
  </li>
  <li><p>I have one truly awful lab I assign, where I make one student per group of three create an extremely thorough testing class for a larger set of classes coded by their peers.  Through some fairly thorough (albeit informal) polling, the students who have to go through that portion of the lab say that they have a much better idea of how to test code (though they do <em>not</em> come out enthusiastic about it.)</p>
  </li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-20T16:14:02.797Z
Answers.LastActivityDate: 2017-06-20T16:14:02.797Z
Answers.LastEditDate: 2020-06-18T08:36:57.023Z
Answers.UserDisplayName: Ben I.
Answers.Body: <p>One approach could be to use their classmates for assistance.</p>
  
  <p>Assign a project.  Explain that each person is going to do the project, and then they will hand the resulting code over to another student (probably randomly assigned).  That student will then test the code.</p>
  
  <ul>
  <li>The writer will get credit for whether or not the code worked correctly.</li>
  <li>The verifier will get credit for correctly identifying whether the code worked or did not.</li>
  </ul>
  
  <p>An interesting variant on this might be to offer extra credit for verification tasks.  Students may submit their work early and have their work put in a pile of programs to verify.  Students may choose to do verification for extra credit, in which case they are assigned a random program from the pile.  To get the extra credit they either need to:</p>
  
  <ul>
  <li>Declare that the program works, and it in fact works when you (the teacher) test the program.
  
  <ul>
  <li>You may require some documentation showing how thorough the testing was.</li>
  </ul></li>
  <li>Document a test case which demonstrates that the program fails which the teacher agrees with.</li>
  </ul>
  
  <p>In the latter case, the program is kicked back to the original writer, along with the results of this Q&amp;A test.  The results will probably be a lot of programs where the original writer relies on the verifier to do the testing, but these are also the students who are going to need some extra-credit to make up for their poor scores on the programs, so hopefully they'll try to verifiy some other student's code.  If they do, they'll learn the value of testing that way!</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-20T19:25:04.873Z
Answers.LastActivityDate: 2017-06-20T19:25:04.873Z
Answers.UserDisplayName: Cort Ammon
Answers.Body: <p>I think it is important to stress that computers "do what you tell them, not what you think you tell them".  From there, testing is a way to see if what you've told them to do is what you think you've told them to do.</p>
  
  <p>I would do this by comparing it to something they understand.  At that age group, it could be something completely unrelated to computers.  For example, do <a href="http://www.centexeweek.org/activities/peanut-butter-and-jelly" rel="nofollow noreferrer">the Peanut Butter and Jelly Sandwich Experiment</a> where one student writes down how to make a PB&amp;J sandwich and a different student follows those instructions exactly. (the results are usually <em>not</em> a sandwich).</p>
  
  <p>Lastly, I would try to teach testing not as a "thing you do at the end" but something you do along the way.  A professional programmer tests their code every few lines.  I start my programs as a "Hello, world!" program and I run it just to make sure I have my headers and other boilerplate correct. Then I replace the "Hello, world!" statement with a few lines that implement the basics of the program (maybe just open the file and close it). I then test that. I keep doing these iterations along the way. (A good explanation of this is in 
  <a href="http://rads.stackoverflow.com/amzn/click/020161586X" rel="nofollow noreferrer">The Practice of Programming</a> by Kernighan and Pike.</p>
  
  <p>If your students learn to test after every few lines they'll learn faster, be less frustrated as they code, and gain more satisfaction from coding.  They'll learn faster, because they'll get faster feedback.  They'll be less frustrated because they won't have dozens (or hundreds?) of errors to deal with at a time.  They'll gain more satisfaction because their code will work better.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-21T17:19:42.370Z
Answers.Text: I really hate this damned machine /
  I wish that they would sell it. /
  It never does quite what I want /
  But only what I tell it.
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-21T17:18:18.973Z
Answers.LastActivityDate: 2017-06-21T17:18:18.973Z
Answers.UserDisplayName: TomOnTime
Answers.Body: <p>I would take Cort Ammon's suggestion a step further.</p>
  
  <p>Cover the ideas behind testing - I show both TDD and what I actually do which is constantly test my code as I develop. Then give a two part project.</p>
  
  <p>Part 1 - the students implement some library of functions/objects etc.</p>
  
  <p>Part 2 - each kid builds something using another kids library. </p>
  
  <p>Kids are graded on how well and well documented their code is for the next person. This encourages thorough testing as well as well written clear code.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-20T20:40:35.927Z
Answers.Text: This is a nicely conceived lesson.
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-20T20:35:53.910Z
Answers.LastActivityDate: 2017-06-20T20:35:53.910Z
Answers.UserDisplayName: Mike Zamansky
Answers.Body: <p>I'd recommend giving them a test suite with their assignments from the beginning. That way, from the start they'll understand that testing code is something that can be done. The more interested students will probably go ahead and look at the test suite and maybe ask questions about it.</p>
  
  <p>When you get to decently large assignments, you can take a day or two and show them how the "grader" (test suite) actually works. Then you can have them write test suites for their own assignments in advance, for example you can write a test suite in class, and tell them that their homework is to made a program that passes those tests.</p>
  
  <p>This way, the students will get a gradual introduction and really see test suites in action for the whole year while they gradually gain a better understand of what's happening "under the hood".</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-21T01:01:11.993Z
Answers.LastActivityDate: 2017-06-21T01:01:11.993Z
Answers.UserDisplayName: thesecretmaster
Answers.Body: <p>A good way of doing this is showing them (via example) how important it is. </p>
  
  <p>A small piece of code in a lab period can be used to show them how everything falls apart if you don't test your code. Going by:</p>
  
  <p><em>Bugs are small beings, so you need to look for them with a magnifying glass</em>.</p>
  
  <p>Testing is the magnifying glass. </p>
  
  <p>Using a piece of code that, at first glance, looks just fine. Show them that for the input it was made for (but not exclusively for that input) the code works smoothly. </p>
  
  <p>However, given some input (which the program <em>should theoretically</em> be able to handle), the code fails miserably. The key point is the <em>should theoretically</em>. It <em>should</em>, but without testing it, it might as well be that it <strong><em>can't</em></strong>.</p>
  
  <p>This example usually shows why it's important to do tests even where no problems <em>should</em> appear. Because, again, bugs are small things that create big problems.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-20T16:27:47.287Z
Answers.LastActivityDate: 2017-06-20T16:27:47.287Z
Answers.UserDisplayName: ItamarG3
Answers.Body: <p>Tell them a story like this, if you build a boat are you going to cross the big sea straight ahead ? What happens then if you have a leak ? That's what big men do to educate, parrables.</p>
  
  <p>How is it important for your students?
  What does it matter to them <strong>now</strong>, what does it matter to them <strong>in the end</strong>?</p>
  
  <p>Some want to be educated, some just want their degree, some want both, and some want none (these one shall be your masters). From these four categories you can make two categories: those that listen to you and those who do not.</p>
  
  <p>For the purpose of stressing out one matter or another, I think you have two ways, you can either repeat it over and over or teach them a lesson once and for all. </p>
  
  <p>It's so hard to find good examples that it's better to use off subjects ones.
  Do you go on a trip without checking your gas? Are you attacking your enemies without checking your gear?</p>
  
  <p>In the end all of your students will find peace because the ones you think you lost just found another way.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-20T17:03:06.397Z
Answers.Text: Welcome to Computer Science Educators! This answer could really benefit from some details on how this teaches students the importance of testing. Could you add some explanation to your answer?
Answers.UserDisplayName: ItamarG3
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-20T16:51:30.647Z
Answers.LastActivityDate: 2017-06-21T17:38:08.620Z
Answers.LastEditDate: 2017-06-21T17:38:08.620Z
Answers.UserDisplayName: Yvain
Answers.Body: <p>Use a rubric, even for a small assignment, that requires:</p>
  
  <ul>
  <li>two or three incrementally developed, working versions of code</li>
  <li>one non-working version of code with a explanation of the error and how it was identified.</li>
  </ul>
  
  <p>I distribute starter code with a filename like <code>assignment_6_imageArtist_YourNames_v0</code> and ask that teams turn in files labelled with the names and <code>v1</code>, <code>v2</code>, and <code>v3</code> and the non-working version <code>v1.1</code> or <code>v2.5</code> for example. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-03T03:09:54.377Z
Answers.LastActivityDate: 2017-07-03T03:09:54.377Z
Answers.UserDisplayName: Bennett Brown
Answers.Body: <p>You could use some examples, like <a href="https://en.wikipedia.org/wiki/Cluster_(spacecraft)" rel="nofollow noreferrer">Ariane 5 catastrophe</a>:</p>
  
  <blockquote>
    <p>The greater horizontal acceleration caused a data conversion from a
    64-bit floating point number to a 16-bit signed integer value to
    overflow and cause a hardware exception. Efficiency considerations had
    omitted range checks for this particular variable, though conversions
    of other variables in the code were protected. The exception halted
    the reference platforms, resulting in the destruction of the flight.</p>
  </blockquote>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-21T09:12:28.617Z
Answers.Text: This is not a good example to showcase testing. That code had been thoroughly tested, but only in an Ariane 4 context. Ariane 5 required extra tests because the conditions in which this code was called had changed, but the change in conditions had not been detected as important. If it had been detected then people would have updated the code. This example showcases formal methods — that crash prompted Ariane to start doing static analysis.
Answers.UserDisplayName: Gilles 'SO- stop being evil'
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-20T21:04:43.193Z
Answers.LastActivityDate: 2017-06-20T21:04:43.193Z
Answers.UserDisplayName: el.pescado - нет войне
Answers.Body: <p>You could try giving them some problems from competitive programming websites (You can find some very simple problems) which usually give you some sort of test input and also outline the boundaries of which the program must run. Typically in the sample input, they will include test cases that sit near the boundaries of whatever it is you need to solve.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-20T21:20:40.553Z
Answers.Text: Would this be the beginning of a class discussion? Or just a way to make sure that they are exposed to some good test cases? How do you bring the lesson home? In any case, welcome to CSE!
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-20T19:46:15.390Z
Answers.LastActivityDate: 2017-06-20T19:46:15.390Z
Answers.UserDisplayName: andres villa
Answers.Body: <p><strong>Introduce <a href="https://en.wikipedia.org/wiki/Test-driven_development" rel="noreferrer">test-driven development</a>.</strong></p>
  
  <p>TDD and agile methods of development are very popular at the minute, and for good reason — you know, ahead of time, exactly what each part of the program must achieve, and you can confidently say that the program will work as intended as long as your tests are thorough.</p>
  
  <p>I think that sometimes, the confusion begins when students aren't actually sure what they're trying to achieve in the first place, so they're reluctant to test because the code is already so fragile. TDD helps to ensure that there is a <strong>clear specification of behaviour for the code</strong>, so the students are clear on what <em>should</em> happen, and that the code they're written <strong>fulfils the specification</strong>.</p>
  
  <p>Make it clear that <strong>testing is part of the project</strong> in your lessons, and it should help to solve some problems. When students are asked to write a program, they may not realise that writing some tests along with the project (or even beforehand, as in TDD) is a good idea. Having the <em>red-green-refactor</em> cycle would seem helpful here; it will give your students confidence that their code works as intended, and then the ability to clean up and improve their code without breaking it.</p>
  
  <p><a href="https://www.researchgate.net/profile/Christopher_Jones51/publication/234788469_Test-driven_development_goes_to_school/links/551438ec0cf23203199d0c03.pdf" rel="noreferrer">Test-Driven Development Goes To School</a> was interesting reading while I wrote this answer. They evaluated the effects of teaching using TDD at several university courses, with generally mixed/positive results. At Virginia Polytechnic Institute:</p>
  
  <blockquote>
    <ul>
    <li>Code correctness measured as the number of defects per
    thousand lines of code was only 38 for the TDD group compared to 70 for those not using
    test-driven development </li>
    <li>65.3% of students either agreed
    or strongly agreed that TDD increased their confidence in the correctness of their code.</li>
    <li>67.3% either agreed or strongly agreed that TDD increased their confidence
    when making changes to their code base. </li>
    <li>Test completeness was 93.6% for
    TDD; 90.0% for non-TDD.</li>
    </ul>
  </blockquote>
  
  <p>Of course, there is the overhead of writing the tests and understanding how to use a unit testing framework. For smaller projects, this might be an excessive overhead, but for most non-trivial projects, test-driven development can still be useful. If you're only developing a few functions, you might only need a few tests, and it's great preparation for industry, where TDD is very common.</p>
  
  <p>So, in short, don't just stress the importance of testing and hope they listen, <em>integrate it into your teaching</em>. If writing good tests is the norm in your class, it's far more likely that rigorous tests will be written.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-20T16:38:55.077Z
Answers.Text: "testing is part of the project". Golden. If only the ministry-supplied curriculum thought this way.
Answers.UserDisplayName: ItamarG3
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-17T19:14:08.853Z
Answers.Text: Yes, testing needs to be seen as integral, important, and authentically valued. Otherwise, it's just another thing for a student to check off the list---and if you're gonna get a good grade anyway, why bother? 
  
  I tried to teach unit testing in extracurricular support activities, but it didn't stick like I'd hoped. Later, students started working at tech companies and told me, "You should really have taught us unit testing. It's so important!" It's got to be in the curriculum to be effective, imo.
Answers.UserDisplayName: nova
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-20T16:32:29.163Z
Answers.LastActivityDate: 2017-06-20T16:32:29.163Z
Answers.UserDisplayName: Aurora0001
Body: <p>I've run into the issue in the past that students don't test their code, and get into a huge mess when they can't find out what's not working. How can I prove to them (before something like this happens) that testing code is important?</p>
  
  <hr>
  
  <p>This is a class of high school students, grades 9-12 (ages 14-18). The class is mostly made up of sophomores, but has students from all grade levels. </p>
  
  <p>This is in the United States.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-20T16:02:54.597Z
Comments.Text: Could you tell us what's the age or level of the students?
Comments.UserDisplayName: ItamarG3
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-20T16:04:25.183Z
Comments.Text: @ItamarGreen - this is a class of high schoolers, mostly sophomore but a mix of grades 9-12
Comments.UserDisplayName: jacksonwelsh
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-20T16:05:40.017Z
Comments.Text: Could you edit your question to include that information? perhaps use the [tag:high-school] tag to make it clear for readers.
Comments.UserDisplayName: ItamarG3
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-20T17:17:43.057Z
Comments.Text: @Jackson1442. I have no idea what "grade 9" means. Ideally, give us an age range. Failing that, at least tell us what country you're in, so I can go look up your schooling system and edit that information into the question myself.
Comments.UserDisplayName: TRiG
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-20T19:04:55.817Z
Comments.Text: If you can find a way to stress the importance of testing code among a group of developers being paid to develop code, that would be a good start.  Still searching for that one .... =)
Comments.UserDisplayName: Cort Ammon
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-21T06:31:33.610Z
Comments.Text: [*How to Design Programs* (aka HtDP)](http://HtDP.Org/) uses both pre-/postconditions and testing extensively, and it is directed explicitly at high schoolers. Even if you are not using it, there may be some inspiration in there. The authors are currently working on a [draft for a second edition](http://WWW.CCS.NEU.Edu/home/matthias/HtDP2e/Draft/), which you might want to read instead. The material about imperative programming has been removed, and is going to be covered in the as-of-yet unwritten second volume *How to Design Components*, but you can get those chapters from the first edition.
Comments.UserDisplayName: Jörg W Mittag
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-21T09:47:34.307Z
Comments.Text: Have them contemplate the famous D.E.Knuth quote: "Beware of bugs in the above code; I have only proved it correct, not tried it."
Comments.UserDisplayName: Hagen von Eitzen
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-13T20:15:05.243Z
Comments.Text: Please translate sophmore.
Comments.UserDisplayName: ctrl-alt-delor
Tags: <lesson-ideas><secondary-education>
Title: How to stress the importance of testing code?
ThreadText: # How to stress the importance of testing code?
  
  (Asked by: username_0 on 2017-06-20)
  
  I've run into the issue in the past that students don't test their code, and get into a huge mess when they can't find out what's not working. How can I prove to them (before something like this happens) that testing code is important?
  
  ---
  
  This is a class of high school students, grades 9-12 (ages 14-18). The class is mostly made up of sophomores, but has students from all grade levels.
  
  This is in the United States.
  
  **Tags:** lesson-ideas, secondary-education
  
  > **Comments:**
  > **username_1**: Could you tell us what's the age or level of the students?  
  > **username_0**: @ItamarGreen - this is a class of high schoolers, mostly sophomore but a mix of grades 9-12  
  > **username_1**: Could you edit your question to include that information? perhaps use the [tag:high-school] tag to make it clear for readers.  
  > **username_2**: @Jackson1442. I have no idea what "grade 9" means. Ideally, give us an age range. Failing that, at least tell us what country you're in, so I can go look up your schooling system and edit that information into the question myself.  
  > **username_3**: If you can find a way to stress the importance of testing code among a group of developers being paid to develop code, that would be a good start.  Still searching for that one .... =)  
  > **username_4**: [*How to Design Programs* (aka HtDP)](http://HtDP.Org/) uses both pre-/postconditions and testing extensively, and it is directed explicitly at high schoolers. Even if you are not using it, there may be some inspiration in there. The authors are currently working on a [draft for a second edition](http://WWW.CCS.NEU.Edu/home/matthias/HtDP2e/Draft/), which you might want to read instead. The material about imperative programming has been removed, and is going to be covered in the as-of-yet unwritten second volume *How to Design Components*, but you can get those chapters from the first edition.  
  > **username_5**: Have them contemplate the famous D.E.Knuth quote: "Beware of bugs in the above code; I have only proved it correct, not tried it."  
  > **username_6**: Please translate sophmore.  
  
  ---
  
  ## 11 answers
  
  ### Answer by username_16 on 2017-06-20. Score: 12 | Accepted answer
  
  **Introduce [test-driven development](https://en.wikipedia.org/wiki/Test-driven_development).**
  
  TDD and agile methods of development are very popular at the minute, and for good reason — you know, ahead of time, exactly what each part of the program must achieve, and you can confidently say that the program will work as intended as long as your tests are thorough.
  
  I think that sometimes, the confusion begins when students aren't actually sure what they're trying to achieve in the first place, so they're reluctant to test because the code is already so fragile. TDD helps to ensure that there is a **clear specification of behaviour for the code**, so the students are clear on what *should* happen, and that the code they're written **fulfils the specification**.
  
  Make it clear that **testing is part of the project** in your lessons, and it should help to solve some problems. When students are asked to write a program, they may not realise that writing some tests along with the project (or even beforehand, as in TDD) is a good idea. Having the *red-green-refactor* cycle would seem helpful here; it will give your students confidence that their code works as intended, and then the ability to clean up and improve their code without breaking it.
  
  [Test-Driven Development Goes To School](https://www.researchgate.net/profile/Christopher_Jones51/publication/234788469_Test-driven_development_goes_to_school/links/551438ec0cf23203199d0c03.pdf) was interesting reading while I wrote this answer. They evaluated the effects of teaching using TDD at several university courses, with generally mixed/positive results. At Virginia Polytechnic Institute:
  
  > * Code correctness measured as the number of defects per
  >   thousand lines of code was only 38 for the TDD group compared to 70 for those not using
  >   test-driven development
  > * 65.3% of students either agreed
  >   or strongly agreed that TDD increased their confidence in the correctness of their code.
  > * 67.3% either agreed or strongly agreed that TDD increased their confidence
  >   when making changes to their code base.
  > * Test completeness was 93.6% for
  >   TDD; 90.0% for non-TDD.
  
  Of course, there is the overhead of writing the tests and understanding how to use a unit testing framework. For smaller projects, this might be an excessive overhead, but for most non-trivial projects, test-driven development can still be useful. If you're only developing a few functions, you might only need a few tests, and it's great preparation for industry, where TDD is very common.
  
  So, in short, don't just stress the importance of testing and hope they listen, *integrate it into your teaching*. If writing good tests is the norm in your class, it's far more likely that rigorous tests will be written.
  
  > **Comments:**
  > **username_1**: "testing is part of the project". Golden. If only the ministry-supplied curriculum thought this way.  
  > **username_17**: Yes, testing needs to be seen as integral, important, and authentically valued. Otherwise, it's just another thing for a student to check off the list---and if you're gonna get a good grade anyway, why bother?   I tried to teach unit testing in extracurricular support activities, but it didn't stick like I'd hoped. Later, students started working at tech companies and told me, "You should really have taught us unit testing. It's so important!" It's got to be in the curriculum to be effective, imo.  
  
  ---
  
  ### Answer by username_7 on 2017-06-20. Score: 5
  
  The first problem my students always have with this is that they don't even understand *how* to test their code. They've run the program, and it works. So... it must work.
  
  I have two approaches to this, and while they definitely help, I will also be keeping an eye out on the other answers for more pointers.
  
  * The first is simply to create test-cases together. I have not made as formal a lesson about this as I would like to, but I opportunistically will create tests with the class when we code together on the projector.
  
    Thinking about this now, I would want to create a few methods with some non-obvious flaws (such as breaking on empty lists, odd numbers of items in an array, null entries within an array, negative numbers, etc), and provide .jar files with no source code. Ask students to find the errors, and then reflect together on what kinds of tests were helpful.
  * I have one truly awful lab I assign, where I make one student per group of three create an extremely thorough testing class for a larger set of classes coded by their peers. Through some fairly thorough (albeit informal) polling, the students who have to go through that portion of the lab say that they have a much better idea of how to test code (though they do *not* come out enthusiastic about it.)
  
  
  ---
  
  ### Answer by username_3 on 2017-06-20. Score: 5
  
  One approach could be to use their classmates for assistance.
  
  Assign a project. Explain that each person is going to do the project, and then they will hand the resulting code over to another student (probably randomly assigned). That student will then test the code.
  
  * The writer will get credit for whether or not the code worked correctly.
  * The verifier will get credit for correctly identifying whether the code worked or did not.
  
  An interesting variant on this might be to offer extra credit for verification tasks. Students may submit their work early and have their work put in a pile of programs to verify. Students may choose to do verification for extra credit, in which case they are assigned a random program from the pile. To get the extra credit they either need to:
  
  * Declare that the program works, and it in fact works when you (the teacher) test the program.
    + You may require some documentation showing how thorough the testing was.
  * Document a test case which demonstrates that the program fails which the teacher agrees with.
  
  In the latter case, the program is kicked back to the original writer, along with the results of this Q&A test. The results will probably be a lot of programs where the original writer relies on the verifier to do the testing, but these are also the students who are going to need some extra-credit to make up for their poor scores on the programs, so hopefully they'll try to verifiy some other student's code. If they do, they'll learn the value of testing that way!
  
  
  ---
  
  ### Answer by username_8 on 2017-06-21. Score: 3
  
  I think it is important to stress that computers "do what you tell them, not what you think you tell them". From there, testing is a way to see if what you've told them to do is what you think you've told them to do.
  
  I would do this by comparing it to something they understand. At that age group, it could be something completely unrelated to computers. For example, do [the Peanut Butter and Jelly Sandwich Experiment](http://www.centexeweek.org/activities/peanut-butter-and-jelly) where one student writes down how to make a PB&J sandwich and a different student follows those instructions exactly. (the results are usually *not* a sandwich).
  
  Lastly, I would try to teach testing not as a "thing you do at the end" but something you do along the way. A professional programmer tests their code every few lines. I start my programs as a "Hello, world!" program and I run it just to make sure I have my headers and other boilerplate correct. Then I replace the "Hello, world!" statement with a few lines that implement the basics of the program (maybe just open the file and close it). I then test that. I keep doing these iterations along the way. (A good explanation of this is in
  [The Practice of Programming](http://rads.stackoverflow.com/amzn/click/020161586X) by Kernighan and Pike.
  
  If your students learn to test after every few lines they'll learn faster, be less frustrated as they code, and gain more satisfaction from coding. They'll learn faster, because they'll get faster feedback. They'll be less frustrated because they won't have dozens (or hundreds?) of errors to deal with at a time. They'll gain more satisfaction because their code will work better.
  
  > **Comments:**
  > **username_7**: I really hate this damned machine / I wish that they would sell it. / It never does quite what I want / But only what I tell it.  
  
  ---
  
  ### Answer by username_9 on 2017-06-20. Score: 3
  
  I would take username_3's suggestion a step further.
  
  Cover the ideas behind testing - I show both TDD and what I actually do which is constantly test my code as I develop. Then give a two part project.
  
  Part 1 - the students implement some library of functions/objects etc.
  
  Part 2 - each kid builds something using another kids library.
  
  Kids are graded on how well and well documented their code is for the next person. This encourages thorough testing as well as well written clear code.
  
  > **Comments:**
  > **username_7**: This is a nicely conceived lesson.  
  
  ---
  
  ### Answer by username_10 on 2017-06-21. Score: 2
  
  I'd recommend giving them a test suite with their assignments from the beginning. That way, from the start they'll understand that testing code is something that can be done. The more interested students will probably go ahead and look at the test suite and maybe ask questions about it.
  
  When you get to decently large assignments, you can take a day or two and show them how the "grader" (test suite) actually works. Then you can have them write test suites for their own assignments in advance, for example you can write a test suite in class, and tell them that their homework is to made a program that passes those tests.
  
  This way, the students will get a gradual introduction and really see test suites in action for the whole year while they gradually gain a better understand of what's happening "under the hood".
  
  
  ---
  
  ### Answer by username_1 on 2017-06-20. Score: 2
  
  A good way of doing this is showing them (via example) how important it is.
  
  A small piece of code in a lab period can be used to show them how everything falls apart if you don't test your code. Going by:
  
  *Bugs are small beings, so you need to look for them with a magnifying glass*.
  
  Testing is the magnifying glass.
  
  Using a piece of code that, at first glance, looks just fine. Show them that for the input it was made for (but not exclusively for that input) the code works smoothly.
  
  However, given some input (which the program *should theoretically* be able to handle), the code fails miserably. The key point is the *should theoretically*. It *should*, but without testing it, it might as well be that it ***can't***.
  
  This example usually shows why it's important to do tests even where no problems *should* appear. Because, again, bugs are small things that create big problems.
  
  
  ---
  
  ### Answer by username_11 on 2017-06-20. Score: 1
  
  Tell them a story like this, if you build a boat are you going to cross the big sea straight ahead ? What happens then if you have a leak ? That's what big men do to educate, parrables.
  
  How is it important for your students?
  What does it matter to them **now**, what does it matter to them **in the end**?
  
  Some want to be educated, some just want their degree, some want both, and some want none (these one shall be your masters). From these four categories you can make two categories: those that listen to you and those who do not.
  
  For the purpose of stressing out one matter or another, I think you have two ways, you can either repeat it over and over or teach them a lesson once and for all.
  
  It's so hard to find good examples that it's better to use off subjects ones.
  Do you go on a trip without checking your gas? Are you attacking your enemies without checking your gear?
  
  In the end all of your students will find peace because the ones you think you lost just found another way.
  
  > **Comments:**
  > **username_1**: Welcome to Computer Science Educators! This answer could really benefit from some details on how this teaches students the importance of testing. Could you add some explanation to your answer?  
  
  ---
  
  ### Answer by username_12 on 2017-07-03. Score: 0
  
  Use a rubric, even for a small assignment, that requires:
  
  * two or three incrementally developed, working versions of code
  * one non-working version of code with a explanation of the error and how it was identified.
  
  I distribute starter code with a filename like `assignment_6_imageArtist_YourNames_v0` and ask that teams turn in files labelled with the names and `v1`, `v2`, and `v3` and the non-working version `v1.1` or `v2.5` for example.
  
  
  ---
  
  ### Answer by username_13 on 2017-06-20. Score: 0
  
  You could use some examples, like [Ariane 5 catastrophe](https://en.wikipedia.org/wiki/Cluster_(spacecraft)):
  
  > The greater horizontal acceleration caused a data conversion from a
  > 64-bit floating point number to a 16-bit signed integer value to
  > overflow and cause a hardware exception. Efficiency considerations had
  > omitted range checks for this particular variable, though conversions
  > of other variables in the code were protected. The exception halted
  > the reference platforms, resulting in the destruction of the flight.
  
  > **Comments:**
  > **username_14**: This is not a good example to showcase testing. That code had been thoroughly tested, but only in an Ariane 4 context. Ariane 5 required extra tests because the conditions in which this code was called had changed, but the change in conditions had not been detected as important. If it had been detected then people would have updated the code. This example showcases formal methods — that crash prompted Ariane to start doing static analysis.  
  
  ---
  
  ### Answer by username_15 on 2017-06-20. Score: 0
  
  You could try giving them some problems from competitive programming websites (You can find some very simple problems) which usually give you some sort of test input and also outline the boundaries of which the program must run. Typically in the sample input, they will include test cases that sit near the boundaries of whatever it is you need to solve.
  
  > **Comments:**
  > **username_7**: Would this be the beginning of a class discussion? Or just a way to make sure that they are exposed to some good test cases? How do you bring the lesson home? In any case, welcome to CSE!  
  
  ---
  
  